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 4C56137DE9D for ; Mon, 13 Apr 2026 12:08:03 +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=1776082083; cv=none; b=sZRtbwgngRtdb89eg4spI3lGyCsnBSZHs6zR8x2ey1MjtAxqqX6XUomMj/EqXUDucvONoxPNuU1LYgFstrsVQoh+2nUYel9+IjoOm73/VscKNcsNoEuXj08sZ01Z6jQy9H8GP/DIUCyTjnjlkT+jUy0Rp+JGfkcxq38SSHX1o3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776082083; c=relaxed/simple; bh=CzuqnndQaPPPqjUDcHDOFEdKl+Mhkbc3sMJIr2VoIz4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ky/GGysN6rUC1k+iDwqiSzko/mCsNx/TuIFiCDpeqPe46hsBRleqTivlQeYktXR0clAe+uwcM1brjsAoRoYdiDcXiBqALy4LCUYY/S+dupachC3l+k2fapcJHWNpo52sAe9KIdl/xwPQWVp9kYnw4Cea6lWVGsczGm6vJALU2N8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LJOkfgOT; 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="LJOkfgOT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61FA4C116C6; Mon, 13 Apr 2026 12:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776082083; bh=CzuqnndQaPPPqjUDcHDOFEdKl+Mhkbc3sMJIr2VoIz4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LJOkfgOTVXrByY/YCoNU6lu20MscwD0d2ytYtsb2/Bx8O3lglxw9ocp+MCjOUI8SA aNET5mN7fRkzdWMeMtQ8XNNRzw86YA117Zh2sNgDQqjsYxVWwag/+ZTLcs0CaXBP9+ royIUr8We6OGDaiHGedLn8kpKo7cY+MBFSad0NRPh584IBJoVDCqBVmhz2TAW4urLp xTqIV+Psi5JFa2+MbdOh6qHfTkk8nMJ0pS2pcLOV8JV7IFy/VEBWOsN+b2L2Kny255 WpRbus1Rh+UnC9UePIJRzB+HcOlS/VAxE+Q5sfi4jzhI5l88JecKsT9VgkVGm9Gzn+ f1yEVSquZdx1A== Message-ID: <80db81dc-99a5-487c-99d8-3ff5a687714a@kernel.org> Date: Mon, 13 Apr 2026 14:07:59 +0200 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 1/3] slab: decouple pointer to barn from kmem_cache_node Content-Language: en-US To: "Christoph Lameter (Ampere)" Cc: Ming Lei , Harry Yoo , Hao Li , Andrew Morton , David Rientjes , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260311-b4-slab-memoryless-barns-v1-0-70ab850be4ce@kernel.org> <20260311-b4-slab-memoryless-barns-v1-1-70ab850be4ce@kernel.org> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/10/26 12:12, Christoph Lameter (Ampere) wrote: > On Wed, 11 Mar 2026, Vlastimil Babka (SUSE) wrote: > >> The pointer to barn currently exists in struct kmem_cache_node. That >> struct is instantiated for every NUMA node with memory, but we want to >> have a barn for every online node (including memoryless). > > Is this breaking the 1-1 association of kmem_cache to numa > nodes? Assuming you mean association of kmem_cache_node to NUMA non-memoryless nodes? Indeed if we didn't separate pointer to barn from kmem_cache_node and started instantiating kmem_cache_node on memoryless NUMA nodes, it would break this 1-1 association. But with the separation, it shouldn't. > I would think you needd local per cpu queues on a memoryless node > for performance but not fake node structures. "barn" is only for handling per cpu queues (sheaves), not the other per-node structures. On memoryless node the sheaves will hold remote objects (as there are no local objects) so it's fine that there's also barn for sheaves with remote objects (and empty sheaves). > Per node access is already > serialized via locks and therefore slow. > > If you break the association of per cpu queues to cpu and kmem_cache_node > to numa_nodes then the code may get complicated. The sheaves "empty on alloc"/"full on free" handling code would be more complicated if the barns didn't exist for memoryless nodes, so it's better if it does. The kmem_cache_node with partial (and other) slab lists keeps not existing on memoryless nodes.