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

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

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

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.

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

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:

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.

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. But when page_owner is already enabled, or the
lighter-weight tools cannot solve (or cannot conveniently solve) the
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.

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