Re: [PATCH v3 0/8] mm/page_owner: Add PID/TGID/COMM and cgroup filtering

[zhen.ni]

在 2026/9/11 19:32, Lorenzo Stoakes (ARM) 写道:
> On Fri, Sep 11, 2026 at 01:06:46PM +0200, David Hildenbrand (Arm) wrote:
> > On 9/11/26 09:58, zhen.ni wrote:
> > > 在 2026/9/9 23:54, Zi Yan 写道:
> > > > On 9 Sep 2026, at 6:28, David Hildenbrand (Arm) wrote:
> > > >
> > > > > Because it results in less kernel code  :)
> > > > >
> > > > > And less kernel code is good. Unless unavoidable.
> > > >
> > > > An alternative is to add BPF hooks like bpf_iter to do the filtering
> > > > and by default, when no BPF program is attached, everything is printed.
> > >
> > > I’ve also thought about a similar approach—perhaps a new bpf_iter type
> > > that could iterate over all pages by PFN. The advantage would be that
> > > you can fully customize what you want to print and what you want to
> > > filter. However, doing so would require refactoring the entire
> > > page_owner, and I’m not sure whether it’s worth pursuing in this
> > > direction.I’d also like to hear everyone’s thoughts on this.
> >
> > Certainly better than having more and more manual filters added to the code base.
>
> Agreed.
>
> bpf seems the ideal fit here I think?
>
> Means that those who want this information can get it and those who don't are
> unaffected.

I have prototyped page_owner bpf_iter and confirmed it is a viable and
valuable direction:

1.Most parameter parsing is offloaded to the existing BPF verifier,
keeping the page_owner kernel-side logic simple.

2.Filtering and printing are delegated to the BPF program, providing
greater flexibility and enabling more complex composite filtering.

I plan to further refine this patch series, but it will likely be
submitted as a separate series, as it represents a different direction.


Thanks,
Zhen