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 B1863DF59 for ; Sat, 9 May 2026 00:44:25 +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=1778287465; cv=none; b=H3k34UWoz5l/HVYoPaB10n8RvYyr9kq+Pt/+Dw1lq/h8cUhaHzjDYFr83qpu4eTFIAmyHjX6iFtGE387Po2Nw6FiDmk4le7qih/GG0i5glcIkvlXkwgabm1ma5fnDexifD4g/j0wJVsWh+HsonLUzvv36S36Wo4j40H7snRVOXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778287465; c=relaxed/simple; bh=NR/CaPbgl/jD4rfo3od8KQ9d3FEAg90PeAHOB5wRLrI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M/RatGcDxZZ8m9m7NrCW0jNTC67dVP4OteAKarRdRNaHnfyQ5XjMkKPc613pndCagrdiuFMvZCyvhMb8gkjsxvVvlds5RKIT9V7KP8ajas1fegCSLMbHFIs7ACB/4vBD2S6ljxWqrd6YhPb3wTHHZ5ULw8kRPUkPHD+f4VMSGIc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PuEMf6At; 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="PuEMf6At" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 036EBC2BCB0; Sat, 9 May 2026 00:44:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778287465; bh=NR/CaPbgl/jD4rfo3od8KQ9d3FEAg90PeAHOB5wRLrI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PuEMf6AtI8QzRcfsbo3mHuGbkjmz/DTjUH1aEAZD5VVpL1IfphrET8f0zOxDbL4nE JFAmCHO9wrYLr3lTTgPBx9KXNlYZnr08aJZIbZIYhIZa140islwBn3iwKlG9vMIp9q fRlDOrrQ//APYsT9YhwnlryJOz+4FYcyWRHX/ddFQXx+bPgia1FVtGCFRpsppWd+jv R/WdLJqukKwcGDGOG4lYw1fIkf/ppQaeWF+5w0S34vRJsnckN6EPFKvKeg1g9kMUql jtLa9gXNQlKdhhYdXby8PyoVvwwZsQywIMfX1ArTGl8CxbUiYyz357lszu7Banc8g4 7qVtz+2sfzyZQ== 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 v5 2/3] mm/page_owner: add NUMA node filter with nodelist support Date: Fri, 8 May 2026 17:44:16 -0700 Message-ID: <20260509004417.84229-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260507064643.179187-3-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 Thu, 7 May 2026 14:46:42 +0800 Zhen Ni wrote: > Add NUMA node filtering functionality to page_owner to allow filtering > pages by specific NUMA node(s). This is useful for NUMA-aware memory > allocation analysis and debugging. > > The filter supports flexible nodelist input formats: > - Single node: echo "0" > nid > - Multiple nodes: echo "0,2,3" > nid > - Node range: echo "0-3" > nid > - Mixed format: echo "0,2-4,7" > nid > - Clear filter: echo > nid (empty string) > > The implementation uses nodemask_t for efficient multi-node filtering > and nodelist_parse() for flexible input parsing. Empty input clears > the filter. > > Note: Access to nid_mask uses plain load/store without locking because > nodemask_t is too large (128 bytes) for READ_ONCE/WRITE_ONCE. This is > safe for debug use: low-frequency changes and torn reads would only > cause temporary inconsistency in debug output. > > Signed-off-by: Zhen Ni > --- > > Changes in v5: > - Optimize nodes_empty() check in page iteration loop > - Add __data_racy qualifier to nid_mask field Adding links to previous revisions [1] would be helpful. > --- > mm/page_owner.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > > diff --git a/mm/page_owner.c b/mm/page_owner.c [...] > @@ -700,6 +707,9 @@ 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; > + bool filter_by_nid = !nodes_empty(mask); > + Shouldn't we separate variable declarations and statements inside a same block? [...] > +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; > + > + /* > + * 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 What is the 100 bytes overhead? > + */ > + if (count > (100 + 6 * MAX_NUMNODES)) > + return -EINVAL; > + > + kbuf = kmalloc(count + 1, GFP_KERNEL); > + if (!kbuf) > + return -ENOMEM; Would it make sense to use kmalloc_objs()? [1] https://docs.kernel.org/process/submitting-patches.html#commentary Thanks, SJ [...]