Re: [PATCH v6 0/3] mm/page_owner: add filter infrastructure for print_mode and NUMA filtering

[Michal Hocko <mhocko@suse.com>]

On Tue 12-05-26 11:11:47, zhen.ni wrote:
> 
> 
> 在 2026/5/11 20:54, Michal Hocko 写道:
> > On Mon 11-05-26 20:40:07, zhen.ni wrote:
> > > 
> > > 
> > > 在 2026/5/11 20:23, Michal Hocko 写道:
> > > > On Mon 11-05-26 11:30:14, Zhen Ni wrote:
> > > > > Solution
> > > > > ========
> > > > > 
> > > > > This patch series introduces a flexible filter infrastructure with
> > > > > two initial filters:
> > > > > 
> > > > > 1. **Print Mode Filter**: Outputs only stack handles instead of
> > > > >      full stack traces. The handle-to-stack mapping can be retrieved
> > > > >      from the existing show_stacks_handles interface. This dramatically
> > > > >      reduces output size while preserving all allocation metadata.
> > > > > 
> > > > > 2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s)
> > > > >      using flexible nodelist format, enabling targeted analysis of memory
> > > > >      issues in NUMA-aware deployments.
> > > > 
> > > > How does this work when there are multiple consumers of the interface?
> > > > E.g per numa tool to watch node lock page_owner information?
> > > > 
> > > I understand your concern about concurrent access. Are you asking
> > > about this scenario?
> > > 
> > > Scenario: Multiple tools monitoring different NUMA nodes
> > >    Tool 1: echo "0" > nid && cat page_owner > node0.log
> > >    Tool 2: echo "1" > nid && cat page_owner > node1.log
> > > 
> > > The current global filter implementation would have race conditions
> > > in this case.
> > 
> > That makes the interface rather broken in my eyes TBH. Is there any way
> > to make the filter local to the fd?
> 
> I agree that the global filter state creates race conditions for
> concurrent consumers.
> 
> Regarding per-fd filters, I've looked into this approach. The main
> challenge is that per-fd filter state would require changing the current
> simple usage model:

> Current usage:
> echo "0" > /sys/kernel/debug/page_owner_filter/nid
> cat /sys/kernel/debug/page_owner

> Per-fd implementation would require:
> - Add ioctl interface and allocate filter state in file->private_data
> - Change page_owner_fops to add .open/.unlocked_ioctl callbacks
> - Provide user-space tool (e.g., ./page_owner_tool --node 0)
> - New UAPI header with ioctl definitions

ioctl is one option. Have you considered to write the filter state to
the page_owner fd to create a local state?

> This would replace the current "echo + cat" interface with a
> tool-based approach.

Which doesn't sound all that terrible comparing to a non-deterministic
behavior of this proposal

> Alternative: Simple mutex protection to serialize
> concurrent filter modifications. Though this doesn't fully address
> concurrent reads, it could mitigate the most obvious race conditions.
> 
> I'm wondering if you have any thoughts on the trade-off here. Since
> page_owner is mainly used for debugging (typically not in concurrent
> scenarios), would a simpler approach like mutex protection or documenting
> this limitation be sufficient?

The thing is that unless you own the whole machine you never know who
might consider information from page_owner interesting to filter and
read. So you might easily get garbage. Not completely terrible
considering this is debugging interface but I believe we can do better
than that.
-- 
Michal Hocko
SUSE Labs