> diff --git a/tools/testing/selftests/bpf/prog_tests/memcg_stat_churn_percpu.c
> b/tools/testing/selftests/bpf/prog_tests/memcg_stat_churn_percpu.c
> new file mode 100644
[ ... ]
> +static void settle_flush(void)
> +{
The settle_flush() comment explains the reset with:
> + * ~15% window asymmetry, enough to invert bpf_matched vs bpf_full on
> + * flush-dominated cases (e.g. "hot": few cgroups churned from many CPUs).
This isn't a bug, but the cases in this file are narrow/wide/widest, and
there is no "hot" case here (or in the sibling tests). The timed reads also
always run with collect_full = 1, so there is no bpf_matched-vs-bpf_full
comparison in this test. Does this example still describe this file, or was
it carried over from another test?
[ ... ]
> +#define CHURN_GAP_US (50 * 1000)
The gap comment just above this says:
> + * pays that flush inside its timed region. This gives all four reads
> + * (file/bpf x matched/full) approximately the same start state and folds the
This isn't a bug, but the sampling loop does one file_pass() and one
bpf_pass() per sample (bpf_pass always sets collect_full = 1), so there are
two reads per sample rather than the "four reads (file/bpf x matched/full)"
described here. Should this be reworded for this test?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28695985027
