Re: [Xen-devel] [PATCH 39/60] x86: optimize loading of GDT at context switch

[Juergen Gross <jgross@xxxxxxxx>]

On 03.07.19 14:21, Andrew Cooper wrote:
> On 03/07/2019 07:30, Juergen Gross wrote:
> > On 02.07.19 18:09, Andrew Cooper wrote:
> > > On 28/05/2019 11:32, Juergen Gross wrote:
> > > > Instead of dynamically decide whether the previous vcpu was using full
> > > "deciding"
> > >
> > > > or default GDT just add a percpu variable for that purpose. This at
> > > "was using a full or default GDT, just add"
> > >
> > > > once removes the need for testing vcpu_ids to differ twice.
> > > >
> > > > Cache the need_full_gdt(nd) value in a local variable.
> > > What's the point of doing this?  I know the logic is rather complicated
> > > in __context_switch(), but at least it is visually consistent.  After
> > > this change, it is asymmetric and harder to follow.
> > This is a hot path. need_full_gdt() needs two compares, of which one is
> > using evaluate_nospec().
> Urgh.  So evalute_nospec() is already broken here because
> need_full_gdt() isn't always_inline, but surely this isn't the only
> example impacted in __context_switch()?  The choice of 'gdt' is
> similarly impacted by the looks of things.
>
> I'd recommend not worrying about evalute_nospec() for now.  There are
> several fundamental problems atm, and Xen 4.13 cannot ship with it in
> this state.
I did a small performance test with this patch and then removed latching
of need_full_gdt(nd) in the local variable:

On a 8 cpu system I started 2 mini-os domains (1 vcpu each) doing a busy
loop sending events to dom0. On dom0 I did a build of the hypervisor via
"make -j 8" and measured the time for that build, then took the average
of 5 such builds (doing a make clean in between).

           elapsed  user   system
Unpatched:  66.51  232.93  109.21
latched:    64.82  232.33  109.18
unlatched:  63.39  231.81  107.49

As there is a small advantage for not latching I'll remove the full_gdt
local variable.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel