On Mon, Jul 28, 2025, James Houghton wrote: > On Wed, Jul 23, 2025 at 2:04 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Jul 07, 2025, James Houghton wrote: > > Right, but we also don't want to wait for the initial fault-in either, no? I.e. > > plumbing in MAP_POPULATE only fixes the worst of the delay, and maybe only with > > the TDP MMU enabled. > > > > In other words, it seems like we need a helper (option?) to excplitly "prefault", > > all memory from within the guest, not the ability to specify MAP_POPULATE. > > I don't want the EPT to be populated. > > In the event of a hugepage being executed, consider another memory > access. The access can either (1) be in the executed-from hugepage or > (2) be somewhere else. > > For (1), the optimization in this series doesn't help; we will often > be stuck behind the hugepage either being destroyed or reconstructed. > > For (2), the optimization in this series is an improvement, and that's > what this test is trying to demonstrate. But this is only true if the > EPT does not have a valid mapping for the GPA we tried to use. If it > does, the access will just proceed like normal. > > This test only times these "case 2" accesses. Now if we didn't have > MAP_POPULATE, then (non-fast) GUP time appears in these results, which > (IIRC) adds so much noise that the improvement is difficult to > ascertain. But with MAP_POPULATE, the difference is very clear. Oh, right, the whole point is to measure fault-in performance. In that case, rather than MAP_POPULATE, can we do the slightly more standard (for VMMs) thing of writing (or reading) memory from host userspace? I don't think it's worth plumbing in extra_mmap_flags just for MAP_POPULATE, in no small part because MAP_POPULATE is effectively best effort, and doesn't work for VM_PFNMAP (or VM_IO). Those quirks shouldn't matter for this case, and _probably_ won't ever matter for any KVM selftest, but it's enough to make me think MAP_POPULATE is a pattern we don't want to encourage. > This test is 100% contrived to consistently reproduce the memory > access timing anomalies that Vipin demonstrated with his initial > posting of this series[1]. Eh, contrived, targeted, same thing :-D > [1]: https://lore.kernel.org/kvm/20240906204515.3276696-3-vipinsh@xxxxxxxxxx/
