Re: [PATCH v1] mm/memory_hotplug: drop "online" parameter from add_memory_resource()

From: David Hildenbrand
Date: Fri Nov 23 2018 - 08:17:37 EST


On 23.11.18 14:05, Michal Hocko wrote:
> On Fri 23-11-18 13:58:16, David Hildenbrand wrote:
>> On 23.11.18 13:54, Michal Hocko wrote:
>>> On Fri 23-11-18 13:37:40, David Hildenbrand wrote:
>>>> User space should always be in charge of how to online memory and
>>>> if memory should be onlined automatically in the kernel. Let's drop the
>>>> parameter to overwrite this - XEN passes memhp_auto_online, just like
>>>> add_memory(), so we can directly use that instead internally.
>>>
>>> Heh, I wanted to get rid of memhp_auto_online so much and now we have it
>>> in the core memory_hotplug. Not a win on my side I would say :/
>>
>> That is actually a good point: Can we remove memhp_auto_online or is it
>> already some sort of kernel ABI?
>>
>> (as it is exported via /sys/devices/system/memory/auto_online_blocks)
>
> I have tried and there was a pushback [1]. That led to a rework of the
> sysfs semantic of onlining btw. The biggest objection against removing was
> that the userspace might be too slow to online memory and memmaps could
> eat the available memory and trigger OOM. That is why I've started
> working on the self hosted memmpas but failed to finish it. Fortunatelly
> Oscar is brave enough to continue in that work.

Yes I saw that work :) . I wonder if it is really an issue or can we
worked around. At least for paravirtualized devices (a.k.a. balloon
devices) - even without the memmaps rework.

E.g. only add a new memory block in case the old one was onlined. And we
get that information via register_memory_notifier(). So we would always
only have one memory block "pending to be onlined".

That's at least my plan for virtio-mem (add one block at a time). The
problem is if some external entity triggers memory hotplug of actual
devices you cannot simply control. Like adding a bunch of ACPI DIMMs in
one shot without userspace being able to keep up.

But the memmaps thingy still is very valuable when wanting to add memory
in an environment where we are already low on memory.

>
> [1] http://lkml.kernel.org/r/20170227092817.23571-1-mhocko@xxxxxxxxxx
>


--

Thanks,

David / dhildenb