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 60B1F3A3830 for ; Mon, 1 Jun 2026 11:28:39 +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=1780313320; cv=none; b=PUCGDHgObERaKqoqNqx+fnfAF5fUDowF+pjX84+S+FFvZLFtACZoDqqQOcfGpoYNqVFjrf1/SWe65yZsZ+celrMMD+oRXugRKnzxa/n5I93Q25PJ4OuFJepUXhKu74YtTRzbcrGPVhn+TqMZB9Jzhr0j1IhGsROdKujoVEO1mEM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780313320; c=relaxed/simple; bh=oR88QN7+FpwU+hsZooKfAHhw9jtB3rO/9jTlnOX4KOs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WhXnrgGKC7kFVeMtsCppzEM7JtwM+Ce5N7Lpl+sAQR+nE/7fRH9Dz1FzhCRATdFauTGzQrnTDCG7qZayuIz8q+D37+8b56jCC7gYrWLT4ljIaXq5IKArA+wbXsHcskmEyX/N+Kl2lIdaAg6Wa/c2+nnavOm9lWwif8jAdenhFGQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BhI57ZVU; 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="BhI57ZVU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50A2D1F00893; Mon, 1 Jun 2026 11:28:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780313319; bh=OdxqPDkGONuSRMCAaVwsXelgusdJH6v/cM6qWrjIlXE=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=BhI57ZVUoZcW7IuNj74YRyvJyWPFtbr7fKRPSavUCOxuGcqwjebxgJhVJalYzAHkN ZDAm+IctEKBm7NNAqoYxGsRwIKl11I2lJc3kmewcCJsAV/sJHwRhr3rjzEjv9xQHv4 AKwduZyqWTZTj3oJj3jq5LGniqflkhOmivvg8AiBNp2HTIlwrcXBFqhJ3Zo1LvZnQz bSTaIGL9Jdp5DorOICI1CxL8hPv4iDFDKwVd73qumbMZZ3ATonFvd/4n/nLIPstHN2 Ah5DEnlhJQ0E0pghVmRLoYLjvVxwyQ+POt/C9anJ11g6mU7GLtdMTi/F4uzhODtVjY a84IeYDjsp/6g== Message-ID: <33506b25-ab2f-4f31-a380-7c0fe65567a3@kernel.org> Date: Mon, 1 Jun 2026 20:28:16 +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 v2] mm/slub: allocate sheaves on local memory nodes To: Hao Li , vbabka@kernel.org, akpm@linux-foundation.org Cc: cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260601095706.106551-1-hao.li@linux.dev> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260601095706.106551-1-hao.li@linux.dev> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------gZR6oAjp607qvy5PQJZS0GJB" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------gZR6oAjp607qvy5PQJZS0GJB Content-Type: multipart/mixed; boundary="------------wYzRs4T6OquX0f6LJe0JbpFA"; protected-headers="v1" From: Harry Yoo To: Hao Li , vbabka@kernel.org, akpm@linux-foundation.org Cc: cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Message-ID: <33506b25-ab2f-4f31-a380-7c0fe65567a3@kernel.org> Subject: Re: [PATCH v2] mm/slub: allocate sheaves on local memory nodes References: <20260601095706.106551-1-hao.li@linux.dev> In-Reply-To: <20260601095706.106551-1-hao.li@linux.dev> --------------wYzRs4T6OquX0f6LJe0JbpFA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/1/26 6:56 PM, Hao Li wrote: > Sheaf structs are exchanged through node-local barns. Since barn struct= s > are already allocated from their local NUMA node, this patch aims to > allocate sheaf structs from their local memory nodes as well. >=20 > To achieve this, the obvious choice would be using cpu_to_mem(). > However, init_percpu_sheaves() and bootstrap_cache_sheaves() iterate > through possible CPUs, whereas cpu_to_mem() is only initialized for > online CPUs. Therefore, we cannot use cpu_to_mem() and instead need to > use local_memory_node(cpu_to_node(cpu)), similar to what > __build_all_zonelists() does. >=20 > The primary goal of this patch is to improve NUMA node locality. > Although the actual performance impact is minor, it still yields a ~1% > improvement on a 192-core, 8-NUMA-node system when testing with the > will-it-scale mmap test case. Oh, nice :) I have a question though... I wonder if would be better to handle this by e.g.) not returning empty sheaves back to barn and freeing them if the node id doesn't match and it's not a memoryless node. init_percpu_sheaves() and bootstrap_cache_sheaves() are not the only places that can allocate sheaves from remote nodes; sheaves allocation could fall back to other nodes and then SLUB could keep reusing those sheaves from remote nodes even after memory is reclaimed. If this works well, we probably don't need to handle it in init_percpu_sheaves() and bootstrap_cache_sheaves() at all as they will eventually be freed, while covering the other case too? > Signed-off-by: Hao Li > --- > Changes in v2: > - Make init_percpu_sheaves() use a NUMA-aware sheaf struct allocation t= oo. > (Thanks Harry) > - Rebase on latest code. >=20 > v1: https://lore.kernel.org/linux-mm/20260525082312.16012-1-hao.li@linu= x.dev/ --=20 Cheers, Harry / Hyeonggon --------------wYzRs4T6OquX0f6LJe0JbpFA-- --------------gZR6oAjp607qvy5PQJZS0GJB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCah1s0AAKCRCGXBN6rc5S 1pYiAQC8Uw1BtxMqKzwMMtAlDU2HaGd9Jsqp71ILar6fE1WNjwD5AWcpRWU6LqFK qQGFNs4d+y0k1XJbJcwpMPhueKqtEAo= =RumH -----END PGP SIGNATURE----- --------------gZR6oAjp607qvy5PQJZS0GJB--