From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (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 392D63876D0 for ; Wed, 24 Jun 2026 08:17:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782289063; cv=none; b=iorKhodB+GU9p/bh+Zl14fwntpQXFMRrkAuv+cgZHF1srf4F4UAu1GCidDne+eCrRrv7cXQLXFUe812f3kq0pwv/dAuuI1zbeNnUHGBKj/qjWBLXryDKr8AvpRjMve6TWY/BEpLOZv9KzRGJR5YDD512sqk4vJblgA/toOJcOQ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782289063; c=relaxed/simple; bh=8XW+HNWzHP/3XlpBrhR7+rz8kBt9NgTupwJUN7l8i3s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gGIZfBqbQPLdzUhzZ1w33MkT3KxIFnn8AKEYCN7Rm4F9wER7u30/uKVja2Ugf7iV2G/J5qIR5PXG0wUn5ThYrfddnrXLCSSG69M3+GeYHCe2haj35mVGJ2iE9w8vFeE/FY6Y5QFhhlH5b+6gswghzZOnobm9zs/ZMsY8LcBEgKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=xfX5P/kx; arc=none smtp.client-ip=91.218.175.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="xfX5P/kx" Date: Wed, 24 Jun 2026 16:17:27 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782289056; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Y/nKRSL+C76nTG6IfkT7RdZALB2h8ggPQxXITJrd/wQ=; b=xfX5P/kxONqYtqmA8LrK8K1LITzFURH7e1PZyKzNPO+yvNYToXWHi6s0KDn9x71zptkoUl Yx+MZA70sl/l9O4+KMEXR4exfwXrufcsRt58lBoystT5PRAJOR4NUHzQwdZg7IxKZJRfDa uch/goecRjkznyDLNiSYZUjhWZdRou8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Hao Li To: Harry Yoo Cc: vbabka@kernel.org, akpm@linux-foundation.org, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/slub: deduplicate NUMA policy calculation in allocation paths Message-ID: References: <20260623110952.411041-1-hao.li@linux.dev> <0c69b68d-7c67-4d3a-9f90-86a56bc229e7@kernel.org> 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=us-ascii Content-Disposition: inline In-Reply-To: <0c69b68d-7c67-4d3a-9f90-86a56bc229e7@kernel.org> X-Migadu-Flow: FLOW_OUT On Wed, Jun 24, 2026 at 02:14:55PM +0900, Harry Yoo wrote: > > > On 6/23/26 8:04 PM, Hao Li wrote: > > Currently, alloc_from_pcs() and __slab_alloc_node() both calculate the > > NUMA policy independently. Since they are called consecutively in paths > > like __kmalloc_nolock_noprof() and slab_alloc_node(), this leads to > > redundant code snippets. > > Right. > > > Introduce a helper function to resolve the NUMA policy once, eliminating > > the duplicated code and reducing execution overhead. > > Nice. > > > Also remove __slab_alloc_node() function because it is almost empty. > > Nice! > > > The callers of __slab_alloc_node now call ___slab_alloc() directly. > > > > Additional notes: > > > > Previously, when slab_strict_numa was enabled, alloc_from_pcs() and > > __slab_alloc_node() could each resolve the task mempolicy, so > > MPOL_INTERLEAVE or MPOL_WEIGHTED_INTERLEAVE could advance the > > interleave state twice for a single object allocation attempt. > > > > With this change, the strict NUMA node is resolved once and reused by > > both alloc_from_pcs() and ___slab_alloc(). > > Nice catch! > > > This is a behavior change, but it better matches the intent of > > selecting one policy node for one allocation attempt. > > Right. > > and I think backporting is unnecessary here. > > > Signed-off-by: Hao Li > > --- > > Changes in v2: > > * Use a better function name apply_strict_numa_policy() (Thanks Harry) > > * Remove almost empty function __slab_alloc_node. > > * Add a local variable, strict_node, so the retry path in > > __kmalloc_nolock_noprof() computes the strict NUMA node from the original > > node parameter instead of a previously resolved node value. > > What about overriding 'node' before retry label instead? > > node = apply_strict_numa_policy(node); > [...] > retry: > [...] > I agree! I originally used a separate strict_node variable mostly to keep the old retry behavior intact. But looking at it now, the retry is really just an internal fallback for the same requested object allocation. There's no strong reason to advance the MPOL_INTERLEAVE or MPOL_WEIGHTED_INTERLEAVE state again on each retry. > Otherwise LGTM. Thanks! -- Thanks, Hao