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

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

在 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