On Fri, 2018-02-02 at 11:10 -0800, Linus Torvalds wrote: > On Fri, Feb 2, 2018 at 10:50 AM, Linus Torvalds > <torva...@linux-foundation.org> 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.
smime.p7s
Description: S/MIME cryptographic signature
