[lkml]   [2020]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v1 5/5] mm/memory_hotplug: allow to specify a default online_type
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 <>
>> Cc: Andrew Morton <>
>> Cc: Michal Hocko <>
>> Cc: Oscar Salvador <>
>> Cc: "Rafael J. Wysocki" <>
>> Cc: Baoquan He <>
>> Cc: Wei Yang <>
>> Signed-off-by: David Hildenbrand <>
> 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.




David / dhildenb

 \ /
  Last update: 2020-03-16 16:49    [W:0.065 / U:2.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site