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

[zhen.ni]

在 2026/9/8 22:30, David Hildenbrand (Arm) 写道:
> On 9/7/26 10:26, Zhen Ni wrote:
> > This patch series adds process and memory cgroup filtering support to
> > page_owner. Following the previous series that introduced print_mode and
> > NUMA node filters:
> >    https://lore.kernel.org/linux-mm/20260707115411.1714314-1-zhen.ni@xxxxxxxxxxxx/
> >
> > This series adds filtering capabilities to page_owner, allowing users to
> > filter output by specific processes and memory cgroups. Users can now
> > filter page_owner output by PID, TGID, COMM (with wildcard support), and
> > memory cgroup path. This makes page_owner debugging more focused and
> > efficient for tracking memory allocations in specific contexts.
> >
> > Targeted filtering provides significant performance benefits on large memory
> > servers by reducing both execution time and output size. By filtering at the
> > kernel level before reading, only relevant page allocations are processed,
> > dramatically reducing the amount of data that needs to be handled in userspace.
>
> page_owner is used for debugging. Why do we have to add kernel code to make it
> faster?
>
> How much faster are we talking about?

On my VM with just 2GB of RAM, the raw page_owner output takes real
0m6.178s. Filter it down to PID 1, and it drops to real 0m0.286s. Handle
mode takes real 0m0.938s — roughly an 85% speedup. I've also tried this
on a 1TB server, and it's very slow. The numbers would look even more
extreme.

You're right that execution time isn't the main concern for a debug
tool. But that's kind of the point — I'm trying to optimize the current
execution flow of page_owner, reduce unnecessary overhead, and make the
tool more user-friendly (especially for servers with 1TB+ of memory).If
the user only cares about a specific slice of memory, why dump
everything from the kernel side and then filter it all over again in
userspace? Might as well filter at the source.

> Or are there other limits to actually implementing it without kernel pre-filtering?