From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m19731104.qiye.163.com (mail-m19731104.qiye.163.com [220.197.31.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DB36492514 for ; Tue, 12 May 2026 08:32:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.104 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574736; cv=none; b=Q+mRNCH+DYHG5Y1HAIg45IUuO58Usya+9b2ncPIvS66AZ5+6GIOpgRgdHzpDjxm7MHcScF1kyFRqZAq3wvmSqnYPAHMu4Cmx7KJT3YOqtIyiGWdWB7RMeX5Nw6VrKhhLIcy2NIWWpp9JWOsJ/JSHFYeF2hq6o5oVyYEBkfztPzU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574736; c=relaxed/simple; bh=WlZ+cgq97soFSk0ibG3clIHm1jnV3dXUpIlpVoTNgbk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GWeAGT7FRVvwe4/sou89xBub+LAB8npN0tLQmj1L6bzqQeyFMcAsTO8H8GnBMhYMGpaUP77R6FW3e/pBwaWSJWT4HJHr1/fyKmVNJuHwuE1ae3ixWVGoja/A6GRuqo6DXQCRIjVxhEvtU+eVtuNM0nV6E0mupNiBxy5MJmH7nuw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn; spf=pass smtp.mailfrom=easystack.cn; arc=none smtp.client-ip=220.197.31.104 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=easystack.cn Received: from [192.168.0.59] (unknown [218.94.118.90]) by smtp.qiye.163.com (Hmail) with ESMTP id 1a0401d4f; Tue, 12 May 2026 16:16:37 +0800 (GMT+08:00) Message-ID: Date: Tue, 12 May 2026 16:16:36 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 0/3] mm/page_owner: add filter infrastructure for print_mode and NUMA filtering To: Michal Hocko Cc: akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260511033017.747781-1-zhen.ni@easystack.cn> <4a06f50f-fb7a-4b5a-a9d7-664407f83472@easystack.cn> From: "zhen.ni" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9e1b4266d90229kunme41633f242f17 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVlDSRpOVh5NT00dSRpKGU0ZHlYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVCQk lOS1VKS0tVSkJLQlkG 在 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