Re: [patch v4] mm: vmstat_kunit: add synthetic benchmark for vm stats

[David Rientjes <rientjes@google.com>]

On Mon, 28 Sep 2026, David Hildenbrand (Arm) wrote:

> On 9/18/26 22:39, David Rientjes wrote:
> > From: Christoph Lameter <cl@gentwo.org>
> > 
> > Add a synthetic benchmark that can be used to measure performance of VM
> > statistics.  This is used to analyze any improvements or regressions in
> > functions that are frequently used in hot code paths.
> > 
> > The test is run by KUnit or doing modprobe vmstat_kunit directly.
> > 
> > Sample output:
> >  KTAP version 1
> >  1..1
> >  KTAP version 1
> >  # Subtest: vmstat
> >  # module: vmstat_kunit
> >       1..3
> >       # vmstat_test_inc_dec_zone_page_state: 10000 ops: inc_zone_page_state -> 8 cycles (4 ns/op), dec_zone_page_state -> 9 cycles (4 ns/op)
> >       ok 1 vmstat_test_inc_dec_zone_page_state
> >       # vmstat_test_interleaved_zone_page_state: 10000 ops: inc/dec pair -> 17 cycles (8 ns/op)
> >       ok 2 vmstat_test_interleaved_zone_page_state
> >       # vmstat_test_count_vm_event: 10000 ops: count_vm_event -> 4 cycles (2 ns/op)
> >       ok 3 vmstat_test_count_vm_event
> >  # vmstat: pass:3 fail:0 skip:0 total:3
> >  # Totals: pass:3 fail:0 skip:0 total:3
> >  ok 1 vmstat
> > 
> > Assisted-by: Gemini:gemini-3.8-flash
> > Signed-off-by: Christoph Lameter <cl@gentwo.org>
> > Signed-off-by: David Rientjes <rientjes@google.com>
> > ---
> > v4:
> >  - included sample output in the commit description
> >  - switched to NR_MLOCK which is display only so no side effects
> >  - remove unnecessary "rem" variable
> > 
> > Once we're happy with this change, I'll apply the same treatment to the
> > proposed pgalloc and slab tests.
> > 
> >  MAINTAINERS             |   1 +
> >  mm/Kconfig              |  11 +++
> >  mm/Makefile             |   1 +
> >  mm/tests/vmstat_kunit.c | 157 ++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 170 insertions(+)
> >  create mode 100644 mm/tests/vmstat_kunit.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3b2eb2a7a89a..de09076d91b9 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -17161,6 +17161,7 @@ F:	mm/ptdump.c
> >  F:	mm/sparse-vmemmap.c
> >  F:	mm/sparse.c
> >  F:	mm/sparse.h
> > +F:	mm/tests/vmstat_kunit.c
> >  F:	mm/util.c
> >  F:	mm/vmpressure.c
> >  F:	mm/vmstat.c
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 604c58199acb..2d021fb5ace6 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -1511,6 +1511,17 @@ config LAZY_MMU_MODE_KUNIT_TEST
> >  
> >  	  If unsure, say N.
> >  
> > +config VMSTAT_KUNIT_TEST
> > +	tristate "KUnit test for VM statistics" if !KUNIT_ALL_TESTS
> > +	depends on KUNIT
> > +	default KUNIT_ALL_TESTS
> > +	help
> > +	  Enable this option to test and benchmark the performance of VM
> > +	  statistics updates (zone page state and VM event counters), which
> > +	  are used frequently in hot memory management code paths.
> > +
> > +	  If unsure, say N.
> > +
> >  source "mm/damon/Kconfig"
> >  
> >  endmenu
> > diff --git a/mm/Makefile b/mm/Makefile
> > index e7245cb88c66..3d4f2c43b8d3 100644
> > --- a/mm/Makefile
> > +++ b/mm/Makefile
> > @@ -147,4 +147,5 @@ obj-$(CONFIG_SHRINKER_DEBUG) += shrinker_debug.o
> >  obj-$(CONFIG_EXECMEM) += execmem.o
> >  obj-$(CONFIG_TMPFS_QUOTA) += shmem_quota.o
> >  obj-$(CONFIG_LAZY_MMU_MODE_KUNIT_TEST) += tests/lazy_mmu_mode_kunit.o
> > +obj-$(CONFIG_VMSTAT_KUNIT_TEST) += tests/vmstat_kunit.o
> >  obj-$(CONFIG_MEM_ALLOC_PROFILING) += alloc_tag.o
> > diff --git a/mm/tests/vmstat_kunit.c b/mm/tests/vmstat_kunit.c
> > new file mode 100644
> > index 000000000000..899c957091d1
> > --- /dev/null
> > +++ b/mm/tests/vmstat_kunit.c
> > @@ -0,0 +1,157 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * KUnit synthetic performance benchmark for VM statistics.
> > + *
> > + * (C) 2009 Linux Foundation, Christoph Lameter <cl@gentwo.org>
> > + * (C) 2026 Google LLC, David Rientjes <rientjes@google.com>
> > + */
> > +#include <kunit/test.h>
> > +#include <linux/mm.h>
> > +#include <linux/vmstat.h>
> > +#include <linux/timex.h>
> > +#include <linux/ktime.h>
> > +#include <linux/math64.h>
> > +
> > +#define TEST_COUNT 10000
> > +
> > +static void vmstat_test_free_page(void *arg)
> > +{
> > +	__free_page((struct page *)arg);
> > +}
> > +
> > +/*
> > + * Test 1: Sequential inc_zone_page_state() followed by dec_zone_page_state().
> > + * Net change to zone counters is 0.
> > + */
> > +static void vmstat_test_inc_dec_zone_page_state(struct kunit *test)
> > +{
> > +	struct page *page;
> > +	cycles_t time1, time2, time;
> > +	u64 t1_ns, t2_ns;
> > +	u64 inc_cycles, dec_cycles;
> > +	u64 inc_ns, dec_ns;
> > +	unsigned int i;
> > +
> > +	page = alloc_page(GFP_KERNEL);
> > +	KUNIT_ASSERT_NOT_NULL(test, page);
> > +	KUNIT_ASSERT_EQ(test, kunit_add_action_or_reset(test, vmstat_test_free_page, page), 0);
> > +
> > +	/* Benchmark inc_zone_page_state() */
> > +	time1 = get_cycles();
> > +	t1_ns = ktime_get_ns();
> > +	for (i = 0; i < TEST_COUNT; i++)
> > +		inc_zone_page_state(page, NR_MLOCK);
> 
> Just curious, could some compiler optimizations here change the picture, and
> doing the average would not actually be representative? Not sure if a barrier()
> would reliably avoid that.
> 
> Maybe not relevant today, but I do wonder if we should take care that it stays
> that way.
> 
> Applies to all cases below where we loop.
> This looks much cleaner to me, thanks!
> 

Thanks all for the feedback, answering all three emails here.

Andrew's questions are spot on and his assumptions are correct.  This is
the first of three tests previously posted that measure the execution
times of critical mm functions.  This is the simplest of the tests, the
others are for lots of concurrent allocations through the page allocator
and through the slab allocator.

It's anticipated to be used by developers to measure the impact of any
core changes that would end up causing workload performance issues since
things like vmstats, page allocations, and slab allocations are all hot
paths.  It could also be used to detect regressions over time, from
kernel version to kernel version, independent of development use cases.
So it could certainly be wired up to the kernel test robot.

We've carried this internally in our own test suite since Christoph
posted them back in 2009 :)  We can build with the tests enabled to
measure the impact of any changes in these areas.

The "pass:3" is an artifact of moving this test to kunit, the tests
themselves will not fail and we're only interested in the ns/op.

DavidH: I don't think the compiler can fold or merge the loop bodies, the
compiler shouldn't be able to see through the call to the exported symbol
and actually needs to call it 10,000 times :)  I don't think barrier()
adds anything.

I should make this test depend on CONFIG_VM_EVENT_COUNTERS, however,
otherwise that loop is going to be pretty fast.

If there aren't any concerns, I'll send out a v5 with that change.