[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH] FPU LWP 6/8: create lazy and non-lazy FPU restore functions



>>> On 04.05.11 at 18:33, Wei Huang <wei.huang2@xxxxxxx> wrote:
> Checking whether there is a non-lazy state to save is architectural 
> specific and very messy. For instance, we need to read LWP_CBADDR to 
> confirm LWP's dirty state. This MSR is AMD specific and we don't want to 
> add it here. Plus reading data from LWP_CBADDR MSR might be as expensive 
> as clts/stts.
> 
> My previous email showed that the overhead with LWP is around 1%-2% of 
> __context_switch(). For non lwp-capable CPU, this overhead should be 
> much smaller (only clts and stts) because xfeature_mask[LWP] is 0.

I wasn't talking about determining whether LWP state is dirty, but
much rather about LWP not being in use at all.

> Yes, clts() and stts() don't have to called every time. How about this one?
> 
> /* Restore FPU state whenever VCPU is schduled in. */
> void vcpu_restore_fpu_eager(struct vcpu *v)
> {
>      ASSERT(!is_idle_vcpu(v));
> 
> 
>      /* save the nonlazy extended state which is not tracked by CR0.TS bit */
>      if ( xsave_enabled(v) )
>      {
>          /* Avoid recursion */
>          clts();
>          fpu_xrstor(v, XSTATE_NONLAZY);
>          stts();
>      }

That's certainly better, but I'd still like to see the xsave_enabled()
check to be replaced by some form of lwp_enabled() or
lazy_xsave_needed() or some such (which will at once exclude all
pv guests until you care to add support for them).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.