Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

[David Woodhouse]

On Fri, 2018-02-02 at 11:10 -0800, Linus Torvalds wrote:
> On Fri, Feb 2, 2018 at 10:50 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > 
> > Will it make for bigger code? Yes. But probably not really all *that*
> > much bigger, because of how it also will allow the compiler to
> > simplify some things.
>
> Actually, testing this with my fairly minimal config, it actually
> makes for *smaller* code to inline those things.
> 
> That may be a quirk of my configuration, or maybe I screwed something
> else up, but:
> 
> Â [torvalds@i7 linux]$ size ~/mmu.o arch/x86/kvm/mmu.o
> ÂÂÂÂÂtextÂÂÂÂdataÂÂÂÂÂbssÂÂÂÂÂdecÂÂÂÂÂhex filename
> ÂÂÂÂ85587ÂÂÂÂ9310ÂÂÂÂÂ120ÂÂÂ95017ÂÂÂ17329 /home/torvalds/mmu.o
> ÂÂÂÂ85531ÂÂÂÂ9310ÂÂÂÂÂ120ÂÂÂ94961ÂÂÂ172f1 arch/x86/kvm/mmu.o
> 
> so the attached patch actually shrank things down by about 50 bytes
> because of the code simplification.
> 
> Of course, I have been known to screw up retpoline testing in the
> past, so my numbers are suspect ;). Somebody should double-check me.

I got this:

 Âtext	ÂÂÂdata	ÂÂÂÂbss	ÂÂÂÂdec	ÂÂÂÂhex	
filename
 87167	ÂÂÂ9310	ÂÂÂÂ120	ÂÂ96597	ÂÂ17955	
arch/x86/kvm/mmu.o
 88299	ÂÂÂ9310	ÂÂÂÂ120	ÂÂ97729	ÂÂ17dc1	
arch/x86/kvm/mmu-inline.o

But then, I'd also done kvm_handle_hva() and kvm_handle_hva_range().

Either way, that does look like a reasonable answer. I had looked at
the various one-line wrappers around slot_handle_level_range() and
thought "hm, those should be inline", but I hadn't made the next step
and pondered putting the whole thing inline. We'll give it a spin and
work out where the next performance bottleneck is. Thanks.

Attachment: smime.p7s
Description: S/MIME cryptographic signature