XSAVEOPT

[Konstantin Belousov]

On Mon, Jul 09, 2012 at 11:24:52AM -0400, John Baldwin wrote:
> On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote:
> > Please find at
> > http://people.freebsd.org/~kib/misc/xsaveopt.1.patch
> > a patch to finally add suport for using XSAVEOPT for our amd64 context
> > switch code. See Intel SDM for description of the XSAVEOPT instruction.
> > 
> > Summary is that the instruction allows to not write parts of the FPU
> > state which was not touched by the thread. Context switch then would
> > write less to the PCB when thread is moved out from CPU. This is mainly
> > to facilitate the ever-growing size of the FPU register file, in
> > particular, AVX/YMM registers. Normal applications do not touch YMM, so
> > saving them on each context switch if FPU was used is waste.
> > 
> > Main complication is that any consumer of the ucontext_t still expect to
> > see fully populated machine state, including the extended states which were
> > not saved. Since CPU only avoids save when corresponding state is pristine,
> > we can use the copy of initial state. CPUID provides an enumerator that
> > allows OS to easily pick up neccesary area and copy over.
> > 
> > I tried hard, but was unable to measure any statistically significant
> > difference in the context switch times between XSAVE and XSAVEOPT using
> > lmbench lat_ctx, on Core i7 2600K.
> 
> Hmm, I thought one of the ideas of xsaveopt was to let you just always execute
> it during a context switch and dispense with the need for using the CR0_TS 
> flag at all?  Maybe that isn't true though.  It would seem rather silly to
> switch out the state if you don't need to (when preempting a thread that uses 
> the FPU to run a thread that doesn't and then switching back for example).

To always execute XSAVEOPT, we would need always execute XRSTOR.

Not executing XSAVEOPT is always faster then executing it. In fact, during
the testing, I never seen a situation when x87 of XMM areas would be not
saved by XSAVEOPT. Only YMM registers were omited if the process did not
touched them since start.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20120709/4012cb60/attachment.pgp