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

[zhen.ni]

在 2026/5/12 15:26, Michal Hocko 写道:
> 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.

Thank you for the feedback.

I've been thinking about the per-fd filtering approach you suggested:

## Implementation Plan

1. Add per-fd filtering to page_owner file
   - Add .open/.release/.write callbacks
   - Each file descriptor has its own filter state
   - Write filter commands: "nid=0", "mode=stack_handle"

2. Provide user-space tool
   - Simple CLI: ./page_owner_tool --nid=0
   - Handle fd management internally

## User Experience

Direct access (default: no filter):
  cat /sys/kernel/debug/page_owner

With filtering:
  ./page_owner_tool --nid=0
  ./page_owner_tool --nid=0,2-3
  ./page_owner_tool --nid=0 --mode=stack_handle

## Benefits

- Completely eliminates race condition
- Per-fd isolation for concurrent access
- Correct design for multi-consumer scenarios

Does this approach look good to you?

Please let me know if you have any suggestions or concerns.

Thanks,
Zhen