On 08/11/19 22:26, Andrea Arcangeli wrote: > On Fri, Nov 08, 2019 at 10:02:52PM +0100, Paolo Bonzini wrote: >> kvm_intel.ko or kvm_amd.ko, I'm not sure why that would be worse for TLB >> or RAM usage. The hard part is recording the location of the call sites > > Let's ignore the different code complexity of supporting self > modifying code: kvm.ko and kvm-*.ko will be located in different > pages, hence it'll waste 1 iTLB for every vmexit and 2k of RAM in > average. This is unlikely to make a difference, since kvm.o and kvm-intel.o are overall about 700 KiB in size. You do lose some inlining opportunities with LTO, but without LTO the L1 cache benefits are debatable too. The real loss is in the complexity, I agree with you about that. > Now about the code complexity, it is even higher than pvops: > > KVM pvops > ========= ============= > 1) Changes daily Never change > > 2) Patched at runtime Patched only at boot time early on > during module load > and multiple times > at every load of kvm-*.ko > > 3) The patching points to All patch destinations are linked into > code in kernel modules the kernel > > Why exactly should we go through such a complication when it runs > slower in the end and it's much more complex to implement and maintain > and in fact even more complex than pvops already is? For completeness, one advantage of patching would be to keep support for built-in Intel+AMD. The modpost patch should be pretty small, and since Jessica seemed quite open to it let's do that. Thanks, Paolo > Furthermore by linking the thing statically we'll also enable LTO and > other gcc features which would never be possible with those indirect > calls. > > Thanks, > Andrea >
