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

[Zi Yan <ziy@nvidia.com>]

On 9 Sep 2026, at 6:28, David Hildenbrand (Arm) wrote:

> On 9/9/26 04:35, zhen.ni wrote:
>>
>>
>> 在 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@easystack.cn/
>>>>
>>>> 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.
>
> 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.


Best Regards,
Yan, Zi