Re: [PATCH v6 0/3] mm/page_owner: add filter infrastructure for print_mode and NUMA filtering
From: zhen.ni
Date: Tue May 12 2026 - 02:52:14 EST
在 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:I understand your concern about concurrent access. Are you asking
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?
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