Re: [PATCH v3 0/7] mm/page_owner: add bpf_iter and kfuncs

["zhen.ni" <zhen.ni@easystack.cn>]

在 2026/10/22 02:52, Andrew Morton 写道:
> On Wed, 21 Oct 2026 19:24:30 +0800 Zhen Ni <zhen.ni@easystack.cn> wrote:
> 
>> page_owner records who allocated every page and is a core memory-debug
>> facility, but it currently reaches userspace as the debugfs flat dump:
>> slicing allocations by pid, comm, NUMA node, cgroup or stack, etc.,
>> means streaming and parsing the entire file in userspace, which is
>> expensive on large hosts and hard to query live.
> 
> Confused.  Your series 8570b65220e8 ("mm/page_owner: add print_mode
> filter") addressed this significantly?
> 
> 

Thank you. I'd like to share some background on how this new approach
came about.

After series 8570b65220e8 ("mm/page_owner: add print_mode filter"), I
attempted to further extend the filter capabilities so that userspace
could more selectively capture page owner results. This effort led to
the series [PATCH v3 0/8] mm/page_owner: Add PID/TGID/COMM and cgroup
filtering.

During that discussion, we gradually reached a consensus that "a BPF
iter" might be a better solution to this problem. The main concerns
with continuing to extend the kernel-side filter approach were:

  1. As filter capabilities grow, the kernel side needs to handle
  increasingly complex parameter parsing and various combinations of
  different filter attributes, which is not conducive to maintainability.

  2. More fundamentally, kernel-side filters cannot provide truly
  flexible filtering because the filtering logic is hardcoded in the
  kernel.

At that point, I did a POC to verify the BPF iter direction:

  
https://lore.kernel.org/linux-mm/99a94068-ab37-47c0-878c-7c1ada5204b2@easystack.cn/

It seems there is broad agreement on this direction. This new series is
the implementation of that approach.


Thanks,
Zhen