From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 76C161624D5 for ; Thu, 25 Jun 2026 04:36:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782362161; cv=none; b=O+qA4vyN3JNpPgdIfKc26RZqDHCWfHw2y9WCX6PHk8tMfkdou0xiJF1oiGNKswGVa4ysC+2tr8B3dfUGSFK1pPNTZEyMZRGuI3q64W8IT/B24ezqorXmJkdCwwu3kC5GqJPXZmYfK/V9RstKPUmfN0MKxFjEWg9fKLxkE+zVxi4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782362161; c=relaxed/simple; bh=NxtGZZ4dU1AoG72unZdzuU5n2yk7TnpYWWKZPSTzhwY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OSa9qDq4WOOzjxN2bADmM1twjhOjjs0Na0GN5+sLq2OmpyyxmokP6GNNERGrabClnIheWheriQfJeGyanMZEVZmhvpoFvct4hnfOT4aOvISG6LgWvXhRX75OBMSJWSDPzS3eaRXdJu9FpNdGMGlN7tMEp4K/hEo2JNqgnVsjTUE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NpN3EdnM; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NpN3EdnM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97C9C1F000E9; Thu, 25 Jun 2026 04:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782362160; bh=k7IZdmDL8MjAd2g3mKlIHlMmJKl2AOZ6ZSMg3dG01HY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=NpN3EdnMq5COZ4pNqJntYNX6PYmDSVYTcI/jfeOOwEBn//AokXeym5IuuHSuTo9zZ 8uzSmUWq7bpXBfJBZxTNqXfCG3muRIe6h8dkxDVdqNNlxOxjpwqIuHhsTLtEXDnoz5 Y0JSJ69yyARQeJV1NIUVq+We4RAwEPYMgfdL9RmXHRjZL5xRZv6RTN5vmSuUVEDH8Z dDmqAc8G2InagyKIncyRn3K33XCyYzb+NCayucF1vWnU7t01hvmEi96Wn/Vidq8pqd q7/QwX7/skHyQPWb8zzCr84N7Zo6vwGwF4ld2P8rqbWxLA+JO0q29mn3rZxpew7DP2 e7Zk3Rltc2z3g== Message-ID: Date: Thu, 25 Jun 2026 13:35:52 +0900 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 v3] mm/slub: deduplicate NUMA policy calculation in allocation paths To: Hao Li , vbabka@kernel.org Cc: akpm@linux-foundation.org, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260624100320.430115-1-hao.li@linux.dev> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260624100320.430115-1-hao.li@linux.dev> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------p37cXN42t2U5Il8In8JASo8E" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------p37cXN42t2U5Il8In8JASo8E Content-Type: multipart/mixed; boundary="------------lJ2RIDFhlc40Wbm0G9LQ5N86"; protected-headers="v1" From: Harry Yoo To: Hao Li , vbabka@kernel.org Cc: akpm@linux-foundation.org, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Message-ID: Subject: Re: [PATCH v3] mm/slub: deduplicate NUMA policy calculation in allocation paths References: <20260624100320.430115-1-hao.li@linux.dev> In-Reply-To: <20260624100320.430115-1-hao.li@linux.dev> --------------lJ2RIDFhlc40Wbm0G9LQ5N86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/24/26 7:00 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. >=20 > Introduce a helper function to resolve the NUMA policy once, eliminatin= g > the duplicated code and reducing execution overhead. >=20 > Also remove __slab_alloc_node() function because it is almost empty. > The callers of __slab_alloc_node now call ___slab_alloc() directly. >=20 > Additional notes: >=20 > 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. > And each retry will also advance the interleave state. >=20 > With this change, the strict NUMA node is resolved once and reused by= > both alloc_from_pcs() and ___slab_alloc() in each retry. >=20 > This is a behavior change, but it better matches the intent of > selecting one policy node for one allocation attempt. >=20 > Signed-off-by: Hao Li > --- > Changes in v3: > * Move apply_strict_numa_policy before retry label to simplify code (= Thanks > Harry) >=20 > 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 or= iginal > node parameter instead of a previously resolved node value. > --- Looks good to me, Reviewed-by: Harry Yoo (Oracle) Thanks! --=20 Cheers, Harry / Hyeonggon --------------lJ2RIDFhlc40Wbm0G9LQ5N86-- --------------p37cXN42t2U5Il8In8JASo8E Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCajywKAAKCRCGXBN6rc5S 1kXLAP9rlTI5Z/kvr5TTbZ+UigvqH3OPQen3L7fX5U8UfvA6eAD6A+XoXscA3A2S zcNUfftGxIuMq+tozUeLItLqDJNXDww= =nlzu -----END PGP SIGNATURE----- --------------p37cXN42t2U5Il8In8JASo8E--