[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use
On 13/03/18 13:47, Jan Beulich wrote: > Introduce a synthetic feature flag to use alternative instruction > patching to NOP out all code on entry/exit paths. Having NOPs here is > generally better than using conditional branches. > > Also change the limit on the number of bytes we can patch in one go to > that resulting from the encoding in struct alt_instr - there's no point > reducing it below that limit, and without a check being in place that > the limit isn't actually exceeded, such an artificial boundary is a > latent risk. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > Tested-by: Juergen Gross <jgross@xxxxxxxx> > Reviewed-by: Juergen Gross <jgross@xxxxxxxx> I'm afraid that I still have misgivings about this patch. While I'm quite willing to trust that it functions correctly, it is taking a some code which is almost impossible to follow already, and making it substantially more complicated to follow, for what appears to be a fractional gain. The two distinct areas of concern are the split interrupt re-enablement (which really doesn't buy us anything useful), and how obvious the nopping is (where in the .Lxcpt_cr3_start case, the ALTERNATIVE_NOP is 111 lines (!) away from the code it applies to). I.e. I'm struggling to decide whether it falls into the category of unnecessary micro-optimisation or not. Therefore, I'd like to consider what other XPTI changes we're expecting to get, and whether those have an impact. I've got a patch (which I've not had time to submit upstream yet, but would like to get in for 4.11) which implements a crude "no XPTI for dom0" mode. Performance testing shows that in scenarios running only HVM guests (a very common XenServer setup), the difference between dom0 XPTI-ness can be up to 40% in terms of aggregate network/disk throughput. OTOH, I expect my patch will likely change based on Juergen's series (which I should probably stop using as an excuse to defer). What other changes are we expecting? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |