Messages in this thread | | | Subject | Re: [PATCH v1 5/5] mm/memory_hotplug: allow to specify a default online_type | From | David Hildenbrand <> | Date | Mon, 16 Mar 2020 16:48:36 +0100 |
| |
On 16.03.20 16:31, Michal Hocko wrote: > On Wed 11-03-20 13:30:26, David Hildenbrand wrote: >> 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/state > > I 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.
> >> 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 <bhe@redhat.com> >> Cc: Wei Yang <richard.weiyang@gmail.com> >> Signed-off-by: David Hildenbrand <david@redhat.com> > > 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
| |