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?
Thanks,
Eduard.
[...]
