On Tue, Jul 7, 2026 at 2:38 AM Zenghui Yu <[email protected]> wrote: > > Hi, > > Running cgroup/test_zswap on my arm64 box failed immediately with: > > [root@localhost cgroup]# ./test_zswap > TAP version 13 > 1..8 > # zswpout does not increase after test program > not ok 1 test_zswap_usage > [...] > > I'm sure that pages are successfully written into zswap by checking the > count_memcg_events(.., idx=ZSWPOUT, ..) trace events. But "zswpout_after" > in test_zswap_usage() is 0 and results in this failure. > > I guess the problem is that (in this particular case) the memcg stats has > not been flushed when userspace reads it. > > memcg_stat_format() > mem_cgroup_flush_stats() > __mem_cgroup_flush_stats(.., force=false) > needs_flush = memcg_vmstats_needs_flush(); > > static bool memcg_vmstats_needs_flush(struct memcg_vmstats *vmstats) > { > return atomic_long_read(&vmstats->stats_updates) > > MEMCG_CHARGE_BATCH * num_online_cpus(); > } > > I can image that memcg_vmstats_needs_flush() will return false because I'm > testing a 16k-page-size kernel on a box with 96 cpus.. > > As we have a periodic flusher flushed all the stats every 2 seconds, I use > the following diff to wait the flusher to expose the accurate stats to > userspace. > > diff --git a/tools/testing/selftests/cgroup/lib/cgroup_util.c > b/tools/testing/selftests/cgroup/lib/cgroup_util.c > index 3ce134509041..9596f294da0b 100644 > --- a/tools/testing/selftests/cgroup/lib/cgroup_util.c > +++ b/tools/testing/selftests/cgroup/lib/cgroup_util.c > @@ -95,6 +95,8 @@ int cg_read(const char *cgroup, const char *control, char > *buf, size_t len) > > snprintf(path, sizeof(path), "%s/%s", cgroup, control); > > + sleep(2); > + > ret = read_text(path, buf, len); > return ret >= 0 ? 0 : ret; > } > > I have no idea how to "fix" it properly. Please have a look!
We were discussing a way for userspace to explicitly trigger a flush before, which would come in handy for testing. However, we decided not to expose flushing as a concept to userspace. Unfortunately I think the only way to "fix" the test is to allocate more memory, enough to trigger a flush on most interesting setups. Perhaps we should scale the amount of memory with the number of CPUs so that we don't have to keep playing whack-a-mole.
