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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 9/7/26 06:08, zhen.ni wrote:
> 
> 
> 在 2026/9/4 16:25, Vlastimil Babka (SUSE) 写道:
>> On 9/3/26 06:18, 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.
>> 
>> I wonder about the usefulness of all the new filters. In my experience
>> page_owner is useful to find a kernel memory leak code, and for that the
>> stacktraces are most useful. Dealing with things like pid/tgid/comm/cgroups
>> sounds more like your aim is to profile and optimize particular userspace to
>> use less kernel memory? In that case, isn't it rather the area of memory
>> allocation profiling (or maybe tracing with bpf), not page_owner?
>> 
>> Moreover, tracing or bpf can already do such kind of filtering and AFAIK
>> ftrace filters for tracepoints are nice and generic, while this is adding a
>> bunch of custom parsing and filtering. So that makes me somewhat sceptical.
>> 
> 
> Thanks for the review, and the scepticism is fair - let me first
> clarify where I agree with you, then explain the niche I think these
> filters fill.

Sorry but your whole reply reads like a LLM slop. It took a lot of mental
effor to actually try and engage with it.

> In memory usage source analysis and memory leak analysis, I believe
> page_owner has its own unique niche:
> 
> 1. Nearly all historical allocation records are queryable. Dynamic
>     tracing tools (bpf, ftrace) cannot do this.

This seems totally the opposite. page_owner gives you the current allocation
snapshot. Tracing can provide the full historical record of allocation and
freeing, which can be also postprocessed for snapshots.

> 2. The full allocation stack is recorded via stackdepot. Memory
>     allocation profiling as a code-tagging technique cannot do this.

I think there's some extension (or plan for it), Suren would know better.

> 3. Zero extra usage cost (works as long as page_owner is enabled) and
>     a low barrier to entry (one echo line versus writing a bpf
>     program).
> 
> On the pain points that motivated the series. On production machines
> with large memory configurations (e.g., 250GB+):
> 
> 1. Collecting page_owner information takes minutes to tens of minutes.
> 2. The output is several gigabytes to over 10GB.
> 
> That makes the raw output nearly unreadable and forces post-processing
> with tools/mm/page_owner_sort.c, adding further workload. The root
> causes are:

the "workload" is just cpu time though

> 1. The PFN scan itself - unavoidable, it is the price of page_owner's
>     core function of covering every page.
> 2. Printing every stack for every page - this dominates the cost and
>     is avoidable. stackdepot already deduplicates stacks and keeps a
>     refcount per unique stack; page_owner then re-prints the same stack
>     once per page, and page_owner_sort deduplicates it all over again
>     in userspace.

Since it's avoidable, why mention it at all? Oh I know, LLM slop.

> The filters target exactly this waste: they keep page_owner focused on
> the user's area of interest instead of paying the full print cost.
> 
> On the overlap with dynamic tracing and allocation profiling: the
> features do look similar, but the usage scenarios differ. page_owner
> is not enabled by default on production systems, so most developers
> rightly reach for the lighter-weight tools first - dynamic tracing or
> allocation profiling.

Good! That's an argument against.

> But when page_owner is already enabled, or the
> lighter-weight tools cannot solve (or cannot conveniently solve) the

Adding custom filtering code to kernel vs user convenience is a trade-off.

> problem and enabling page_owner is an option, the advantages above
> kick in: the historical snapshot is filterable in place, and the
> filtered output is small enough to read directly.
> 
> So I see the filters as completing page_owner for the scenarios where
> it is the right tool, rather than competing with the profiling and
> tracing tooling.

I'm not convinced it's worth it.

>>> 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.
>>>
> 
> Thanks,
> Zhen Ni