Re: [Xen-devel] [PATCH 2/3] x86/xsaves: fix overwriting between non-lazy/lazy xsave[sc]

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.02.16 at 10:06, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
> On Fri, Feb 26, 2016 at 01:42:35AM -0700, Jan Beulich wrote:
>> >>> On 26.02.16 at 08:41, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
>> > On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
>> >> >> The description lacks any mention of the performance impact,
>> >> >> and what investigation was done to find ways to perhaps
>> >> >> overcome this. For example, regardless of cpu_has_xsaves,
>> >> >> do we really always need to _use_ XSAVES?
>> >> >> 
>> >> > Currently no supervisor xstates is enabled in xen or even in
>> >> > guest os. Using xsaves is a little ahead (xsavec may used).  
>> >> > xsavec may also cause overwriting problem like xsaves.
>> >> > I will add performance impact in the description. 
>> >> > I am still thinking of a better way to overcome the overhead xsave
>> >> > (But have not get a better solution yet).
>> >> 
>> >> I was thinking that taking into consideration the features a guest
>> >> has ever used (i.e. v->arch.xcr0_accum) to decide which variant
>> >> to use may be a worthwhile avenue to explore.
>> >> 
>> > Oh, Thanks for your suggestion.
>> > You mean when (v->arch.xcr0_accum & (XSTATE_LAZY & ~XSTATE_FP_SSE)) return 
>> > false,
>> > we can return XSTATE_NONLAZY in vcpu_xsave_mask when using xsave[cs]
>> > otherwise return XSTATE_ALL.
>> > It means we can save the area safely, if the guest has ever use 
>> > XSTATE_NONLAZY | XSTATE_FP_SSE only. 
>> 
>> That's one step in the right direction. But the main difference
>> between XSAVE/XSAVEOPT and XSAVEC/XSAVES is that the former
>> can be used incrementally, while the latter can't. And I highly
>> doubt the modified optimization the latter two support will kick in
>> very often, since there's quite good a chance that the guest
>> itself executed another one of these between two of our instances.
>> Which to me means it should at least be investigated whether using
>> XSAVEOPT in favor of XSAVEC wouldn't produce better performance,
>> and whether XSAVES wouldn't better be used only if the guest uses
>> a component which can only be saved that way.
>> 
> Thanks. 
> 
> Ok , I will do the performace test. And can you suggest me some 
> workload/benchmark 
> can be used here to the xsave related performance test ?

Measuring just instruction execution time should be fine for the
purpose here, I think.

> Other thing is from the text above, I guess that the best way to solve 
> xsave[cs]
> problem is:
> 1. use xsaveopt instead of xsave[cs] nowdays.
> 2. use xsaves whenever a component can only be saved that way( when some
>    supervised components are supported in xen).
> 3. no xsavec support.
> 4. xsavec/xsaves feature will expose guest os if point 2 is ok.

Provided this results in better performance than the alternative(s),
yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel