[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8sXFGBYFlG2Z1s4@gourry-fedora-PF4VCD3F>
Date: Fri, 7 Mar 2025 10:56:04 -0500
From: Gregory Price <gourry@...rry.net>
To: Rakie Kim <rakie.kim@...com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org,
joshua.hahnjy@...il.com, dan.j.williams@...el.com,
ying.huang@...ux.alibaba.com, kernel_team@...ynix.com,
honggyu.kim@...com, yunjeong.mun@...com
Subject: Re: [PATCH 0/4] mm/mempolicy: Add memory hotplug support in weighted
interleave
On Fri, Mar 07, 2025 at 03:35:29PM +0900, Rakie Kim wrote:
> Unnecessary sysfs entries: Nodes without memory were included in sysfs
> at boot.
> Missing hotplug support: Nodes that became online after initialization
> were not recognized, causing incomplete interleave configurations.
This comment is misleading. Nodes can "come online" but they are
absolutely detected during init - as nodes cannot be "hotplugged"
themselves. Resources can be added *to* nodes, but nodes themselves
cannot be added or removed.
I think what you're trying to say here is:
1) The current system creates 1 entry per possible node (explicitly)
2) Not all nodes may have memory at all times (memory can be hotplugged)
3) It would be nice to let sysfs and weighted interleave omit memoryless
nodes until those nodes had memory hotplugged into them.
> Dynamic sysfs updates for hotplugged nodes New memory nodes are
> recognized and integrated via the memory hotplug mechanism.
> Subsequent patches refine this functionality:
>
Just going to reiterate that that there's no such this as a hotplug node
or "new nodes" - only nodes that have their attributes changed (i.e.
!N_MEMORY -> N_MEMORY). The node exists, it may just not have anything
associated with it.
Maybe semantic nits, but it matters. The nodes are present and can be
operated on before memory comes online, and that has implications for
users. Depending on how that hardware comes online, it may or may not
report its performance data prior to memory hotplug.
If it doesn't report its performance data, then hiding the node before
it hotplugs memory means a user can't pre-configure the system for when
the memory is added (which could be used immediately).
Hiding the node until hotplug also means we have hidden state. We need
to capture pre-hotplug reported performance data so that if it comes
online the auto-calculation of weights is correct. But if the user has
already switched from auto to manual mode, then a node suddenly
appearing will have an unknown state.
This is why I initially chose to just expose N_POSSIBLE entries in
sysfs, because the transition state causes hidden information - and that
felt worse than extra entries. I suppose I should add some
documentation somewhere that discusses this issue.
I think the underlying issue you're dealing with is that the system is
creating more nodes for you than it should.
~Gregory
Powered by blists - more mailing lists