From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3881147CC81 for ; Tue, 12 May 2026 07:26:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778570792; cv=none; b=gvwyvHUBQm04pipI2C14YyTVr+EgSCCPj0kP+8MjIZIQyUhmOddXd/uS6Qr5KsNVnY2AyBmfNyl5gJh8YcWsggPXF4yPUbJQmtG+W4PBgO4DaMVTOHIm8q5/DO/mbmgqzdziOkP5iX2gYq3pL7a/sxeSgUSMQq/izMB0ZWo3aiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778570792; c=relaxed/simple; bh=r0KaW0qxfPUcqh+GdG0zTMQv2Lcr7v0nEOOcPu3Lvss=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aJng+aPpP/T50pgSojftKnrQcZxnykMirpxJaMpGr/7wL82gr1M5MCHsbqB9LTEXdrDCpg4aALVnF57IFrPG8ssf/JZseU1lwlUqQCB/i8wpxe+N9uaylEg0G2NRKZIpcCHQJMJdbUdZ6OwsolH+cGDHK+OS7ndeN4WxEAFgi7s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=NO7HGRVa; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="NO7HGRVa" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48374014a77so47842825e9.3 for ; Tue, 12 May 2026 00:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1778570783; x=1779175583; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=GCPqNoPPijRV3gL5b6ajQ4oELtZRP2K8OTVs6ADyC/4=; b=NO7HGRVahozg25LO9Jfr76XF+XvlsLsYM9IBGS5c0JXKqW0zXusL+vrtzDcgWNgw33 zpGnmAZCuvM/vj9xl00FIykiEpeXNLyZFRp5WL3Ey5VAZLQpsdCyI+udxRN+jGpOAM+3 wBfbk4iFHXwcCElHtlm7A4dfJKvfowxsfXyzubh5WqP+n1ZBswaeDsFz5VkOeww7M/C+ V8otXP+Tiv0zaFJmGnaI4crvizsRK6/43DSGW148NeAedZ5Di20HTVtWp/atjg0s1X79 K9i72m0vJRVXxZKI4mNs7tWwg865NbOBH/n/XFx1e47C6HoOYc1rSRCmQMUDvrOl65xB csNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778570783; x=1779175583; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GCPqNoPPijRV3gL5b6ajQ4oELtZRP2K8OTVs6ADyC/4=; b=HJvG2bL4PJ+vNt1e516L24VM1ptgcuWTMD+vYJa2rSEmhk+txqoKaGFedn7l3YpQ6w Ja+c3MyxXLjCl31uy9AYprXDlo2Vpl0WATfFFWpMulUYLxiLSOGzMBfiB/sPW3ZeowDg C7BXhd1syNc4WdZam6boQ9vLQrL6HIvMQzhDeOm1qtBpT0+IHi8J4pHVqqI8Oz8PSE9X dWEvZ8qcQcq86Rs99mDOt+iCZG3g34Hh4xIozS7psIqWj8t0z1ToXapkus4hMIczCUA4 qGI9U06laT0VB7Z39YBMrboZ62pj30uP9r8N72eJBw6SBBSFDZE14qKE8UK8i50zN4l8 O4Ew== X-Forwarded-Encrypted: i=1; AFNElJ/y95Y0yOl1eVslUDPjNAR7xanD7ujmjolTwb5PLDMC7d5WUne8gWkGvp6hY/nUyEnvMLJm7zjBHIyEbDY=@vger.kernel.org X-Gm-Message-State: AOJu0Yweea5ZdZXdjaSGdNwme9vPTGHLYJK1aHe+w8GrQLQmY1f43it5 HBtjWUKZMuNaPXVBpJEPIR89tDwXkdCtUdomyTC9r+H81eDRyTOZR81CuyTn2KF4np9splqWXvL skvEq6OU= X-Gm-Gg: Acq92OEQ5oX/0Ogeds3oR3UmoLPglXhrv938DEX5dRY04YFZZ3811s8iDYPu/qUmVwn 60sCw6Xiwn8rrpw7OVxNJy9DyAXj8/k2fRPGzM3351nuO6OGATPftWmRjf6Zi2+2CUdneLT4oet N7fTVMdde84mzxCefpSpFqBn2rKYCgoY+uQP7tR5d3dJNV25GDQQDvwhbh4u630rLOgEbRIpL5H 5jL9qh/HUt1ejZ228Giw4CRkiN1Rig/38nQvVZlqVgKE9r59isFCDObn4BsNT3fbPowGKEz2LxR Wa9agIgSkFaBBU+MkEmIwDOqoW9WC8MnBwtAD+W8rHfWAOxlx6LfagoZnks1fFZeRm7rDmDVxLm 3/zxtjAoJfGX0XBCI9WNFHywWX+H1IAKibw/NsySI2oH4OGvdcBq0vKHi5opOg3hzoipAkeD5M3 XFh5kqk3zOObO4Cb8dM1QU4rXQu0BNpqpqkf4j X-Received: by 2002:a05:600c:6299:b0:489:1c32:210d with SMTP id 5b1f17b1804b1-48e706f120fmr211843515e9.15.1778570783509; Tue, 12 May 2026 00:26:23 -0700 (PDT) Received: from localhost (109-81-80-123.rct.o2.cz. [109.81.80.123]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-454922715b9sm32447501f8f.36.2026.05.12.00.26.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 00:26:23 -0700 (PDT) Date: Tue, 12 May 2026 09:26:22 +0200 From: Michal Hocko To: "zhen.ni" 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 Subject: Re: [PATCH v6 0/3] mm/page_owner: add filter infrastructure for print_mode and NUMA filtering Message-ID: References: <20260511033017.747781-1-zhen.ni@easystack.cn> <4a06f50f-fb7a-4b5a-a9d7-664407f83472@easystack.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4a06f50f-fb7a-4b5a-a9d7-664407f83472@easystack.cn> 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. -- Michal Hocko SUSE Labs