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

[David Hildenbrand (Arm)]

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

Because it results in less kernel code  :)

And less kernel code is good. Unless unavoidable.

-- 
Cheers,

David