|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [PATCH] FPU LWP 6/8: create lazy and non-lazy FPU restore functions
Hi Jan,If we want to make LWP restore optional in vcpu_restore_fpu_eager(), we have to change vcpu_save_fpu() as well. Otherwise, the extended state will become inconsistent for non-LWP VCPUs (because save and restore is asymmetric). There are two approaches: 1. In vcpu_save_fpu(), clean physical CPU's extended state for VCPU which is being scheduled in. This prevents messy states from causing problems. The disadvantage is the cleaning cost, which would out-weight the benefits. 2. Add a new variable in VCPU to track whether nonlazy state is dirty. I think this is better. See the attached file. Let me know if it is what you want. After that, I will re-spin the patches. Thanks, -Wei On 05/05/2011 02:13 AM, Jan Beulich wrote: 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. Attachment:
nonlazy_dirty.txt _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |