From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Donet Tom <donettom@linux.ibm.com>,
Mike Rapoport <rppt@kernel.org>, Zi Yan <ziy@nvidia.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
rafael@kernel.org, Danilo Krummrich <dakr@kernel.org>,
Ritesh Harjani <ritesh.list@gmail.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Alison Schofield <alison.schofield@intel.com>,
Yury Norov <yury.norov@gmail.com>,
Dave Jiang <dave.jiang@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] driver/base: Optimize memory block registration to reduce boot time
Date: Mon, 5 May 2025 15:07:17 +0200 [thread overview]
Message-ID: <aBi4BQAi_zWviDSk@localhost.localdomain> (raw)
In-Reply-To: <da921072-64a8-4ef1-b583-763406e57e8b@redhat.com>
On Mon, May 05, 2025 at 12:36:21PM +0200, David Hildenbrand wrote:
> My thinking was, whether we can simply move the register_cpu_under_node()
> after the try_online_node(). See below regarding early.
>
> And then, remove the !node_online check from register_cpu_under_node().
>
> But it's all complicated, because for memory, we link a memory block to the
> node (+set the node online) when it gets added, not when it gets onlined.
>
> For CPUs, we seem to be creating the link + set the node online when the CPU
> gets onlined.
Yes, that is one think we need to align on.
So, add_memory_resource(), which is part of the hot-add stage, will mark the node
online if it needs to.
I guess that this is done this way because further down the road we rely
on the node to be online for some reason (e.g: online_memory_block() being
called from add_memory_resource()).
Although from the conceptual point of view, it does not make sense, does
it?
I mean, if a node does not have any resources onlined, why should it be
onlined?
But let us assume that that is the way to go, then we could in fact
tweak the cpu-hotplug code to do the same, and online the node whenever
a cpu gets hot-added, and not really waiting for it to be onlined.
I can do some experiments about it and see how it turns out.
> > The first time we hotplug a cpu to the node, note that
> > register_cpu()->register_cpu_under_node() will bail out as node is still
> > offline, so only cpu's sysfs will be created but they will not be linked
> > to the node.
> > Later, online_store()->...->cpu_subsys_online()->..->cpu_up() will take>
> care of 1) onlining the node and 2) register the cpu to the node (so,
> > link the sysfs).
>
>
> And only if it actually gets onlined I assume.
Yes, we only register it if we managed to online the node.
> > I think that ideally, we should only be calling register_cpu_under_node()
> > from register_cpu(), but we have this kinda of (sort of weird?) relation
> > that even if we hotplug the cpu, but we do not online it, the numa node
> > will remain online, and so we cannot do the linking part (cpu <-> node),
> > so we could not really only have register_cpu_under_node() in
> > register_cpu(), which is the hot-add part, but we also need it in the
> > cpu_up()->try_online_node() which is the online part.
>
> Maybe one could handle CPUs similar to how we handle it with memory: node
> gets onlined + link created as soon as we add the CPU, not when we online
> it.
Yes, indeed, as I stated above I think this is the way to go, to have it
paired.
> But likely there is a reason why we do it like that today ...
I cannot think of any (Tm), but it is a possibility.
I will take a break from hugetlb stuff and play a little bit with this.
--
Oscar Salvador
SUSE Labs
prev parent reply other threads:[~2025-05-05 13:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-03 5:40 Donet Tom
2025-05-03 5:40 ` [PATCH v3 2/3] driver/base: remove register_mem_block_under_node_early() Donet Tom
2025-05-03 13:10 ` Zi Yan
2025-05-03 5:40 ` [PATCH v3 3/3] drivers/base : Rename register_memory_blocks_under_node() and remove context argument Donet Tom
2025-05-03 13:10 ` Zi Yan
2025-05-03 13:10 ` [PATCH v3 1/3] driver/base: Optimize memory block registration to reduce boot time Zi Yan
2025-05-04 11:09 ` Mike Rapoport
2025-05-04 16:34 ` Donet Tom
2025-05-04 20:03 ` Andrew Morton
2025-05-05 14:05 ` Mike Rapoport
2025-05-05 7:16 ` David Hildenbrand
2025-05-05 7:28 ` Oscar Salvador
2025-05-05 7:38 ` David Hildenbrand
2025-05-05 7:53 ` Mike Rapoport
2025-05-05 8:18 ` David Hildenbrand
2025-05-05 13:24 ` Mike Rapoport
2025-05-08 9:18 ` David Hildenbrand
2025-05-09 15:40 ` Donet Tom
2025-05-09 21:10 ` Andrew Morton
2025-05-11 6:40 ` Donet Tom
2025-05-11 5:39 ` Mike Rapoport
2025-05-11 12:33 ` Donet Tom
2025-05-05 7:57 ` Oscar Salvador
2025-05-05 8:12 ` David Hildenbrand
2025-05-05 9:36 ` Oscar Salvador
2025-05-05 10:36 ` David Hildenbrand
2025-05-05 12:51 ` Donet Tom
2025-05-05 13:02 ` David Hildenbrand
2025-05-05 16:40 ` Donet Tom
2025-05-05 13:07 ` Oscar Salvador [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBi4BQAi_zWviDSk@localhost.localdomain \
--to=osalvador@suse.de \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=dakr@kernel.org \
--cc=dave.jiang@intel.com \
--cc=david@redhat.com \
--cc=donettom@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=yury.norov@gmail.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox