On 08/05/2026 22.15, David Hildenbrand (Arm) wrote:
On 5/8/26 18:22, [email protected] wrote:
From: Jesper Dangaard Brouer <[email protected]>
Add a selftest to verify the kmem:mm_zone_lock_contended,
kmem:mm_zone_locked, and kmem:mm_zone_lock_unlock tracepoints.
The test has two components:
zone_lock_contention.c - a workload that spawns threads doing rapid
page allocation and freeing to generate zone->lock contention. It
shrinks PCP lists via percpu_pagelist_high_fraction to force frequent
free_pcppages_bulk() and rmqueue_bulk() calls.
test_zone_lock_tracepoints.sh - uses bpftrace to verify tracepoints
exist, have the expected fields, fire under load, and that wait_ns
is populated when contention occurs.
Signed-off-by: Jesper Dangaard Brouer <[email protected]>
---
tools/testing/selftests/mm/Makefile | 2 +
.../mm/test_zone_lock_tracepoints.sh | 212 ++++++++++++++++++
.../selftests/mm/zone_lock_contention.c | 166 ++++++++++++++
This really looks excessive and ... not really how we usually treat tracepoints?
I don't know about others, but I don't think this is really what we want as a MM
selftest.
I wanted to have a program that tested the code I changed, so I simply
made AI write a verification test and asked it to create as a selftest,
that I've run to verify my code change was correctly implemented. As I
needed to trigger lock contention the test is more advanced, but luckily
AI solved it in only the 2nd attempt.
It makes sense to drop this patch. We shouldn't keep this code in the
kernel tree, it simply verified that my code works. There is little
chance that this test will catch meaningful regressions for these
tracepoints.
--Jesper
