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 E50B11C549F for ; Thu, 19 Mar 2026 12:25: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=1773923104; cv=none; b=SyEpmxXBXU4brXU0pyVhY3wpCprG3eoKKkdu9uhIsGXRrf4emJbtBJucretEyOR4SWACjWTfGP2gltCu28s5I5A3mW0YGsrntK7YJr62/x0mouX4OzNHTDeRGzAojAfqW0hGM5O4odY3fUDIrlFtcjQCg+xlTEC1ei3aRKteeYI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773923104; c=relaxed/simple; bh=13bzW+vPo7JVpd4VWsJORrHbXOeJvVF5Iez9fCR2Qwc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tuBpKMSOxqbIYoUnCPXvTvshuMJbxvC3cOtT2w8hw9nZIfDwKvcmHRsawimAfdEzzpHdj+NyjMXFCw+gnshZ0yBvG3xymWWX6CxtKD0k5jAmo9mCRSfDvzPm5mOY4ouWaBfyVP6+Et53LpQYfSm4weUGbTJd1oBT6H3emHOooA4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jeBz6Q50; 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="jeBz6Q50" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08821C19424; Thu, 19 Mar 2026 12:25:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773923103; bh=13bzW+vPo7JVpd4VWsJORrHbXOeJvVF5Iez9fCR2Qwc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jeBz6Q50mjSmjgk9151OjMDFLSzRv01sldtEhypGx/EDX002oxbnWb3Uf/b8dPRkF bKx35gHS+9UidSbuigAvXWpwHe8oEiUmwCNZGkvg/6G57FbQKgcDau6Ui7CNEClSIe a8T0Wv6xvWoinZ5k/ydhjYz7uV/KkiQuxJ0rYxQhXFaieAaQ3lseKZ303/owLyM6Ro Stmr1Tu2Ft5Cl6bh8JX5JR5RddwSN7sR1q/C3FbedCHDhRYFvqFlQrPfkuoStzp8KC hOsNvQw7MQQb0WXxaPw5GFa5qttx7G74g/ybG4HdLVMgB8q4dxg3TwGH0t+rP3U5Ok ts4AL7zZ72WTA== Message-ID: Date: Thu, 19 Mar 2026 13:25:00 +0100 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 2/3] slab: create barns for online memoryless nodes Content-Language: en-US To: Hao Li Cc: Ming Lei , Harry Yoo , Andrew Morton , Christoph Lameter , 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-2-70ab850be4ce@kernel.org> <4xvvslwdcqafc2yfthpgv7panejdgmbdoueqiqkaeikohjutgx@3imnb6zlk6ew> <4659c675-6949-4295-b385-1ab26921a975@kernel.org> <5d10a43f-15d0-4af5-bacb-9924629066a0@kernel.org> <7uyhaxzup5b4qslhf4wnbv4qlafulvlpbn5mpalvurxrlaolvf@2tltqo2qmrsj> From: "Vlastimil Babka (SUSE)" In-Reply-To: <7uyhaxzup5b4qslhf4wnbv4qlafulvlpbn5mpalvurxrlaolvf@2tltqo2qmrsj> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/19/26 12:27, Hao Li wrote: > On Thu, Mar 19, 2026 at 10:56:09AM +0100, Vlastimil Babka (SUSE) wrote: >> > >> > Exactly, conceptually, N_NORMAL_MEMORY seems more precise than N_MEMORY. I took >> > a quick look through the code, though, and it seems that N_NORMAL_MEMORY hasn't >> > been fully handled in the hotplug code. >> >> Huh you're right, the hotplug code doesn't seem to set it. How much code >> that we have is broken by that? > > This probably needs a bit more digging. > >> It seems hotplug doesn't handle it since 2007 in commit 37b07e4163f7 >> ("memoryless nodes: fixup uses of node_online_map in generic code"), >> although the initial support in 7ea1530ab3fd ("Memoryless nodes: introduce >> mask of nodes with memory") did set it from hotplug. > > Yes, this really is quite an old issue. It looks like we may need to dig > through the git history a bit more carefully. > > I'd be happy to dig into it further. Great! > >> >> > Given that, I think it makes sense to use N_MEMORY for now, and then switch to >> > N_NORMAL_MEMORY later once the handling there is improved. >> >> So I'll do this: >> >> diff --git a/mm/slub.c b/mm/slub.c >> index 01ab90bb4622..fb2c5c57bc4e 100644 >> --- a/mm/slub.c >> +++ b/mm/slub.c >> @@ -6029,7 +6029,7 @@ static __always_inline bool can_free_to_pcs(struct >> slab *slab) >> * point to the closest node as we would on a proper memoryless node >> * setup. >> */ >> - if (unlikely(!node_isset(numa_node, slab_nodes))) >> + if (unlikely(!node_state(numa_node, N_MEMORY))) > > Looks good to me. > > I've gone through the full series, including the range-diff updates, and the > rest looks good to me. > Feel free to add my rb-tag to three updated patches. Thanks! > > Reviewed-by: Hao Li Thanks, updated in slab/for-next > >> goto check_pfmemalloc; >> #endif >> >> >> >> >> >> I don't know if with CONFIG_HAVE_MEMORYLESS_NODES it's possible that >> >> numa_mem_id() (the closest node with memory) would be ZONE_MOVABLE only. >> >> Maybe let's hope not, and not adjust that part? >> >> >> > >> > I think that, in the CONFIG_HAVE_MEMORYLESS_NODES=y case, numa_mem_id() ends up >> > calling local_memory_node(), and the NUMA node it returns should be one that >> > can allocate slab memory. So the slab_node == numa_node check seems reasonable >> > to me. >> > >> > So it seems that the issue being discussed here may only be specific to the >> > CONFIG_HAVE_MEMORYLESS_NODES=n case. >> >> Great. Thanks! >>