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

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

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?

Thanks,
Zhen