From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m49239.qiye.163.com (mail-m49239.qiye.163.com [45.254.49.239]) (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 E870C4DD6C4 for ; Tue, 12 May 2026 06:41:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.254.49.239 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778568091; cv=none; b=bp4bITFMxZTIwEp/n5nuKelAPMI87kgRBEhIAPEmEcrW7zYTnYAtXt5pzhUV9AUFf0D5zl0e66+Ni2nZ/UKSeQX0qP6qWgBJM1LHvi6IFbSdCGdXvR9+F/n5yZXaGVsWkHwwzN715Vk9sxC+aiEOnMdM8mc3BaYZqnWOQx34iA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778568091; c=relaxed/simple; bh=oQgDkG0N40y1kd1cNCNks0gUgUzJN5qo64O7MlFZmRE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=p5heq6KaM0hdwrVx100jMbb2h+4Nx+1fhfpZd2c4GsC4GmMWkxG7HO9knC3Y0xEEeIb8GL7TF/Ens6tMcVlUrrKpswENtew+8naZO/6PMdSSuVbMx62Uh2omwOvzoeUPsnufTh9+M6r5/7Vw2xCl+zgwcqqPVlmRkuGKYrlnHVQ= 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=45.254.49.239 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 1a00190df; Tue, 12 May 2026 11:11:47 +0800 (GMT+08:00) Message-ID: <4a06f50f-fb7a-4b5a-a9d7-664407f83472@easystack.cn> Date: Tue, 12 May 2026 11:11:47 +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> From: "zhen.ni" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9e1a2b54b70229kunm95556d052beb2 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVkZGE8dVk9OHUhJTh5PH0NDSVYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVCQk lOS1VKS0tVSkJLQlkG 在 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