Re: [PATCH v2 0/8] mm/page_owner: Add PID/TGID/COMM and cgroup filtering
From: zhen.ni
Date: Mon Sep 07 2026 - 22:47:10 EST
在 2026/9/7 23:21, Vlastimil Babka (SUSE) 写道:
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@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.
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.
This reply was written by me, and its viewpoints are not simply copied directly from an LLM. The LLM only assists with the wording.
Here you completely misunderstood my meaning, perhaps I did not express it clearly.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.
The biggest difference between page_owner and dynamic tracing tools is that page_owner traverses all currently allocated pages using PFN; whereas dynamic tracing tools can only view pages after the observation point is established. The pages collected by page_owner include those from relatively early in the kernel — as long as they are still occupying memory, they can be detected. This is what I mean by "historical allocation records."
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.
I have previously researched the code and documentation of Memory allocation profiling, so this viewpoint is not directly copied from an LLM. The reason I think it cannot record stacks is: its design goal is to be lightweight and usable in production environments, therefore it chose the code-tagging approach. If it recorded stacks, it would already deviate from its original design goal.
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
This workload is not just CPU — printing the stack takes up the vast majority of it.
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.
I feel like you haven't really understood what I'm trying to express.
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.
You may keep your opinion. I think you haven't carefully read my reply, or you simply assumed this is just an automated reply from an LLM.
Perhaps you haven't actually used page_owner on a server with very large memory to investigate memory usage or leak issues (for example, the NIC ring buffer usage problem cannot be solved with dynamic tracing tools). Once you've used it, you'll know how much you need a filter.
Thanks,
Zhen