lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ