On Tue, 2025-02-25 at 16:50 -0800, Sean Christopherson wrote: > On Tue, Feb 25, 2025, Maxim Levitsky wrote: > > On Tue, 2025-02-18 at 17:13 -0800, Sean Christopherson wrote: > > > My understanding is that the behavior is deliberate. Per Yu[1], page_idle/bitmap > > > effectively isn't supported by MGLRU. > > > > > > [1] https://lore.kernel.org/all/CAOUHufZeADNp_y=Ng+acmMMgnTR=ZGFZ7z-m6O47O=CmJauWjw@xxxxxxxxxxxxxx > > > > Hi, > > > > Reading this mail makes me think that the page idle interface isn't really > > used anymore. > > I'm sure it's still used in production somewhere. And even if it's being phased > out in favor of MGLRU, it's still super useful for testing purposes, because it > gives userspace much more direct control over aging. I also think that page_idle is used somewhere in production, and it probably works more or less correctly with regular non VM processes, although I have no idea how well it works when MGLRU is enabled. My point was that using page_idle to track guest memory is something that is probably not used because it doesn't work that well, and nobody seems to complain. However I don't ask for it to be removed, although a note of deprecation might be worth it if really nobody uses it. > > > Maybe we should redo the access_tracking_perf_test to only use the MGLRU > > specific interfaces/mode, and remove its classical page_idle mode altogher? > > I don't want to take a hard dependency on MGLRU (unless page_idle gets fully > deprecated/removed by the kernel), and I also don't think page_idle is the main > problem with the test. > > > The point I am trying to get across is that currently > > access_tracking_perf_test main purpose is to test that page_idle works with > > secondary paging and the fact is that it doesn't work well due to more that > > one reason: > > The primary purpose of the test is to measure performance. Asserting that 90%+ > pages were dirtied is a sanity check, not an outright goal.
