[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |