On Tue, Sep 1, 2026 at 12:13 PM Joshua Hahn <[email protected]> wrote: > > The test_no_invasive_cgroup_shrink selftest checks that when a cgroup > has zswapped out more pages than memory.zswap.max, that it does not > trigger writeback for other cgroups. To do this, it compares the > writeback count in a control cgroup and makes sure that it is 0, > and compares it to the writeback count in a aggressor cgroup who > does expect to see writeback. > > When the zswap shrinker is enabled however, there is an additional path > to zswap writeback, which can happen independently of reaching the > memory.zswap.max limit. > > The writeback counter cannot distinguish between invasive noisy-neighbor > driven writeback and the zswap shrinker work, so the test becomes > invalid.
I think writeback in the control group (zw_group) happens right during the first round of memory allocation, but there shouldn't be any on the second round (as the second round involves writing to wb_group only). So if we read zswap writeback counter of that cgroup (zw_group) right after that first allocation round, and make sure delta = 0 after the second round, then that should work for both shrinker_enabled = Y v.s N. If it's still too noisy, then I'm fine with skipping it when shrinker_enabled = Y.
