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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel