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

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

在 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.

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