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
