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

[Shakeel Butt <shakeel.butt@linux.dev>]

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.

thanks,
Shakeel