From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 F33EF18A6D4 for ; Wed, 29 Apr 2026 01:28:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777426092; cv=none; b=gUkMEiLgDrkXiaJ0kY/a6+Z0zGoZNdf9cjUnp8x1Kg5iOw8o+ftyPk2I6kkJ+l2CsaYil5YCUwJdvrJEeAOqWySeqd+0FX6lh49zfslftQf/og9lFB4FdvNVPlX2XVmxOyBKXiTvn4Z84nKF5/S3wWJzmTHsTmMWP7e6ll0OoNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777426092; c=relaxed/simple; bh=hPmW3aRW/dS3Mxdu7xWuh9u96u1FK7Av/9Ub98It8dE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fxE+ZGgRrHMseZ1l/ttKp8YeAUCQE+WDjgMqnNkqG/BG0UPXra1JTItfZK/vtNL1elYgepz4ufgrDkTOZEydhwj6Im26zHgt1xDyCf7zNSnmg1x9n2GtZP85+I3O7V0ctB2Wlar5Wt0it1PgH0GsFXZyW20YEWfsY8tL9Bpr3AM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RvMszETl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RvMszETl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F9FFC2BCB7; Wed, 29 Apr 2026 01:28:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777426091; bh=hPmW3aRW/dS3Mxdu7xWuh9u96u1FK7Av/9Ub98It8dE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RvMszETlUwA4QkD/70hzdFhRtsxr89zs9j36DsdTApcyDEUxVoDPL614p1Tql/nbO 2BstWktSObWkLKyFzon8hqjSSEvXfnSxBS6cnhZQpKaQdnzS4DbO9L88zNFNhTvuzs BicQ61w6PFUxss7S7hE+n1Z52udiTv+UR0VtuCYM1PD0WDz5j+AO9HoMZf2e5Xsxr2 Vx/m6lirxrkxcnpiHOO7/izhA56dPbvSkOkgHrtC2+9/jTV6H2wbIaPqhOjeXUU6gm LKsXiZQ9ZBakjYcc7S7p5HQXmiC4C29vJ20AqXZ4keboX2kOAip/jF2AnzG/5cxGMa WwTBg7TNWKMsQ== From: SeongJae Park To: Zhen Ni Cc: SeongJae Park , akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 3/4] mm/page_owner: add NUMA node filter with nodelist support Date: Tue, 28 Apr 2026 18:28:07 -0700 Message-ID: <20260429012808.88831-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260428071112.1420380-4-zhen.ni@easystack.cn> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 28 Apr 2026 15:11:11 +0800 Zhen Ni wrote: > Add NUMA node filtering functionality to page_owner to allow > filtering pages by specific NUMA node(s) using nodelist format. > > The filter allows users to focus on pages from specific NUMA nodes, > which is useful for NUMA-aware memory allocation analysis and debugging. > > Supported input formats: > - Single node: echo "2" > nid > - Multiple nodes: echo "0,2,3" > nid > - Node range: echo "0-3" > nid > - Mixed format: echo "0,2-4,7" > nid > - Disable filter: echo "-1" > nid > > Link: https://lore.kernel.org/linux-mm/20260417154638.22370-4-zhen.ni@easystack.cn/ > Link: https://lore.kernel.org/linux-mm/20260419155540.376847-4-zhen.ni@easystack.cn/ Seems the above two links are for v1 and v2 of this patch. I think putting those with the context at commentary area [1] could be useful. > Suggested-by: Zi Yan > Signed-off-by: Zhen Ni > --- [...] > diff --git a/mm/page_owner.c b/mm/page_owner.c > index 6d87b6948cfa..e674a374669a 100644 > --- a/mm/page_owner.c > +++ b/mm/page_owner.c > @@ -685,6 +685,7 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos) > struct page_ext *page_ext; > struct page_owner *page_owner; > depot_stack_handle_t handle; > + nodemask_t mask; > > if (!static_branch_unlikely(&page_owner_inited)) > return -EINVAL; > @@ -698,6 +699,8 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos) > while (!pfn_valid(pfn) && (pfn & (MAX_ORDER_NR_PAGES - 1)) != 0) > pfn++; > > + mask = owner_filter.nid_mask; > + READ_ONCE() was used for owner_filter.print_mode. Should nid_mask also read using READ_ONCE()? > /* Find an allocated page */ > for (; pfn < max_pfn; pfn++) { > /* > @@ -730,6 +733,14 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos) > if (unlikely(!page_ext)) > continue; > > + /* NUMA node filter using bitmask */ > + if (!nodes_empty(mask)) { > + int nid = page_to_nid(page); > + > + if (!node_isset(nid, mask)) > + goto ext_put_continue; > + } > + > /* > * Some pages could be missed by concurrent allocation or free, > * because we don't hold the zone lock. > @@ -1009,6 +1020,75 @@ DEFINE_SIMPLE_ATTRIBUTE(page_owner_print_mode_fops, > &page_owner_print_mode_get, > &page_owner_print_mode_set, "%lld"); > > +static ssize_t nid_filter_write(struct file *file, > + const char __user *buf, > + size_t count, loff_t *ppos) > +{ > + char *kbuf; > + nodemask_t mask; > + int ret; > + int val; > + > + /* > + * Limit input size to handle worst-case nodelist (all nodes). > + * Worst case per node: ",NNNNN" (comma + 5-digit node number) = 6 bytes. > + * Formula: 100 bytes overhead + 6 * MAX_NUMNODES > + */ > + if (count > (100 + 6 * MAX_NUMNODES)) > + return -EINVAL; > + > + kbuf = kmalloc(count + 1, GFP_KERNEL); > + if (!kbuf) > + return -ENOMEM; > + > + if (copy_from_user(kbuf, buf, count)) { > + ret = -EFAULT; > + goto out_free; > + } > + kbuf[count] = '\0'; > + > + /* Support: "-1" to clear, or nodelist format like "0", "0,2", "0-3" */ > + if (kstrtoint(kbuf, 10, &val) == 0 && val == -1) > + nodes_clear(mask); > + else if (nodelist_parse(kbuf, mask)) { > + ret = -EINVAL; > + goto out_free; > + } Doesn't empty string input to nodelist_parse() clears the mask? Can't it be reused? > + > + owner_filter.nid_mask = mask; > + ret = count; > + > +out_free: > + kfree(kbuf); > + return ret; > +} > + > +static int nid_filter_show(struct seq_file *m, void *v) > +{ > + nodemask_t mask = owner_filter.nid_mask; > + > + if (nodes_empty(mask)) > + seq_puts(m, "-1\n"); > + else > + seq_printf(m, "%*pbl\n", nodemask_pr_args(&mask)); > + > + return 0; > +} > + > +static int nid_filter_open(struct inode *inode, struct file *file) > +{ > + return single_open(file, nid_filter_show, NULL); > +} > + > +static const struct file_operations nid_filter_fops = { > + .owner = THIS_MODULE, > + .open = nid_filter_open, > + .read = seq_read, > + .llseek = seq_lseek, > + .write = nid_filter_write, > + .release = single_release, > +}; > + > > static int __init pageowner_init(void) > { > @@ -1024,6 +1104,8 @@ static int __init pageowner_init(void) > filter_dir = debugfs_create_dir("page_owner_filter", NULL); > debugfs_create_file("print_mode", 0600, filter_dir, NULL, > &page_owner_print_mode_fops); > + debugfs_create_file("nid", 0600, filter_dir, NULL, > + &nid_filter_fops); Why don't you use 'page_owner_' prefix like other fops, for consistency? > > dir = debugfs_create_dir("page_owner_stacks", NULL); > debugfs_create_file("show_stacks", 0400, dir, > -- > 2.20.1 [1] https://docs.kernel.org/process/submitting-patches.html#commentary Thanks, SJ