On Mon, Sep 30, 2024 at 9:43 AM Vipin Sharma <vipinsh@xxxxxxxxxx> wrote: > > On Wed, Sep 25, 2024 at 4:51 PM David Matlack <dmatlack@xxxxxxxxxx> wrote: > > > > On 2024-09-13 02:43 PM, Vipin Sharma wrote: > > > This series is extracted out from the NUMA aware page table series[1]. > > > MMU shrinker changes were in patches 1 to 9 in the old series. > > > > I'm curious how you tested this series. Would it be posisble to write a > > selftest to exercise KVM's shrinker interactions? I don't think it needs > > to be anything fancy to be useful (e.g. just run a VM, trigger lots of > > shrinking, and make sure nothing blows up). > > My testing was dropping caches (echo 2 > /proc/sys/vm/drop_caches) in > background while running dirty_log_perf_test selftest multiple times. > I added printk in shrink_count() and shrink_scan() to make sure pages > are being reported and released. > > I can write a test which can spawn a thread to drop caches and a VM > which touches all of its pages to generate page faults. Only downside > is it will not detect if KVM MMU shrinker is being invoked, counting > and freeing pages. > > > > > There appears to be a debugfs interface which could be used to trigger > > shrinking from a selftest. > > > > https://docs.kernel.org/admin-guide/mm/shrinker_debugfs.html > > This is interesting and it does what is needed to test KVM MMU > shrinker. However, this needs CONFIG_DEBUG_FS and > CONFIG_SHRINKER_DEBUG. I think using shrinker_debugfs will be better, > selftest can just skip if it cannot find shrinker_debugfs files. One > downside is that this test will not run if these configs are not > enabled. > > Which one do you prefer? I am preferring shrinker_debugfs but > concerned about its dependency on those two configs, not sure if it is > okay to have this kind of dependency in a selftests. Configs are there to be enabled. If shrinker_debugfs is the right way to test this, I don't see any reason to shy away from using it.
