Re: [PATCH 0/3] selftests/bpf: compare BPF and memory.stat memcg stat readers

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-07-06 at 18:50 -0700, Shakeel Butt wrote:
> On Mon, Jul 06, 2026 at 05:17:50PM -0700, Eduard Zingerman wrote:
> > On Fri, 2026-07-03 at 21:56 -0700, Ziyang Men wrote:
> > 
> > [...]
> > 
> > Hi Ziyang,
> > 
> > I'm a bit hesitant adding 2.5K lines of code to the BPF selftests,
> > as this code would need to be (a) maintained, (b) run at each CI invocation.
> > Hence, the tests added need to be relevant for the BPF sub-system.
> > 
> > Regarding the benchmarking part, as you state yourself:
> > 
> >   > In my testing (a 60-CPU VM) the BPF path is roughly an order of magnitude
> >   > faster than the per-cgroup memory.stat parse for a whole-tree scan, mainly
> >   > because it avoids the per-cgroup open/read and string parsing.
> > 
> > With this, I think the benchmarking code can be dropped altogether.
> > 
> > Next, the three memcg_stat_{reader,churn,churn_percpu}.c files share a
> > lot of utility code almost verbatim (e.g. tree definition/construction).
> > Such duplication should be avoided.
> > 
> > Finally, from the BPF point of view the test exercises the following functionality:
> > - kfuncs:
> >   - bpf_mem_cgroup_page_state
> >   - bpf_mem_cgroup_vm_events
> >   - bpf_put_mem_cgroup
> >   - bpf_get_mem_cgroup
> > - main iterator logic.
> > 
> > All kfuncs but bpf_get_mem_cgroup() are thin wrappers around mm/memcontrol.c code,
> > all kfuncs including the bpf_get_mem_cgroup() are already exercised in the selftests.
> > The iterator logic itself is covered by 8 sub-tests in the prog_tests/cgroup_iter.c.
> > Hence two questions:
> > - What do these new tests add in terms of tests coverage?
> > - Why do BPF selftests need to exercise the churn and churn_percpu scenarios?
> > 
> > Shakeel, could you please comment as well?
> 
> Hi Eduard,
> 
> Thanks a lot for taking a look. The main motivation I had behind requesting
> Ziyang to send this series (beside making him learn the tooling and process of
> sending patches to lkml) was to have a reference implementation and performance
> comparison for BPF based cgroup/memcg stats collection.
> 
> However you have correctly pointed out that selftests might not be the right
> place for such kind of code as selftests are more focused on functional tests
> and run by a lot of CIs while this is a performance benchmarking code.
> 
> I am wondering if there is a place for this benchmarking code in kernel under
> tools folder but archiving it on lkml might be good enough and should be easily
> searchable. Anyways thanks again for your time.

Hi Shakeel,

We do have bpf benchmarks in the kernel tree, the entry point is
tools/testing/selftests/bpf/bench.c. These are supposed to be
performance measurements and are executed manually from time to time
(quite rarely, as far as I understand), not by CI.
However, if I understand Ziyang's assessment correctly, this code is
not really a performance test, but kind of a load test.

Thanks,
Eduard