On Tue, Jan 16, 2024 at 10:19:09AM -0600, Michael Roth wrote: > So at the very least, if we went down this path, we would be worth > investigating the following areas in addition to general perf testing: > > 1) Only splitting directmap regions corresponding to kernel-allocatable > *data* (hopefully that's even feasible...) > 2) Potentially deferring the split until an SNP guest is actually > run, so there isn't any impact just from having SNP enabled (though > you still take a hit from RMP checks in that case so maybe it's not > worthwhile, but that itself has been noted as a concern for users > so it would be nice to not make things even worse). So the gist of this whole explanation why we end up doing what we end up doing eventually should be in the commit message so that it is clear *why* we did it. > After further discussion I think we'd concluded it wasn't necessary. Maybe > that's worth revisiting though. If it is necessary, then that would be > another reason to just pre-split the directmap because the above-mentioned > lazy acceptance workload/bottleneck would likely get substantially worse. The reason for that should also be in the commit message. And to answer: https://lore.kernel.org/linux-mm/20221219150026.bltiyk72pmdc2ic3@xxxxxxx/ yes, you should add a @npages variant. See if you could use/extend this, for example: https://lore.kernel.org/r/20240116022008.1023398-3-mhklinux@xxxxxxxxxxx Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
