Re: [PATCH v1 5/5] mm/memory_hotplug: allow to specify a default online_type
From: David Hildenbrand <hidden>
Date: 2020-03-16 15:49:05
Also in:
linux-hyperv, linux-mm, lkml
On 16.03.20 16:31, Michal Hocko wrote:
On Wed 11-03-20 13:30:26, David Hildenbrand wrote:quoted
For now, distributions implement advanced udev rules to essentially - Don't online any hotplugged memory (s390x) - Online all memory to ZONE_NORMAL (e.g., most virt environments like hyperv) - Online all memory to ZONE_MOVABLE in case the zone imbalance is taken care of (e.g., bare metal, special virt environments) In summary: All memory is usually onlined the same way, however, the kernel always has to ask userspace to come up with the same answer. E.g., HyperV always waits for a memory block to get onlined before continuing, otherwise it might end up adding memory faster than hotplugging it, which can result in strange OOM situations. Let's allow to specify a default online_type, not just "online" and "offline". This allows distributions to configure the default online_type when booting up and be done with it. We can now specify "offline", "online", "online_movable" and "online_kernel" via - "memhp_default_state=" on the kernel cmdline - /sys/devices/systemn/memory/auto_online_blocks just like we are able to specify for a single memory block via /sys/devices/systemn/memory/memoryX/stateI still strongly believe that the whole interface is wrong. This is just adding more lipstick on the pig. On the other hand I recognize that the event based onlining is a PITA as well. The proper interface would somehow communicate the type of the memory via the event or other sysfs attribute and then the FW/HV could tell that this is an offline memory, hotplugable memory or just an additional memory that doesn't need to support hotremove by the consumer. The userspace or the kernel could handle the hotadd request much more easier that way.
Yeah, and I proposed patches like that which were not well received [1] [2]. But then, user space usually wants to online all memory the same way right now. Also, HyperV and virtio-mem don't want to wait for onlining to happen in user space, because it slows down the whole "add a hole bunch of memory" process.
quoted
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Baoquan He <redacted> Cc: Wei Yang <redacted> Signed-off-by: David Hildenbrand <redacted>That being said, I will not object to this patch. I simply gave up fighting this interface. So if it works for consumers and it doesn't break the existing userspace (which is shouldn't AFAICS) then go ahead.
As it solves a real problem and makes the interface to auto online usable, I don't think anything speaks against it. Thanks! [1] https://spinics.net/lists/linux-driver-devel/msg118337.html [2] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg32420.html -- Thanks, David / dhildenb