Message-ID: <5ed312d3-bc2d-38da-166e-452ae3df9e81@redhat.com>
Date:   Mon, 16 Mar 2020 16:48:36 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linuxppc-dev@...ts.ozlabs.org, linux-hyperv@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oscar Salvador <osalvador@...e.de>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Baoquan He <bhe@...hat.com>,
        Wei Yang <richard.weiyang@...il.com>
Subject: Re: [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 <gregkh@...uxfoundation.org>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Michal Hocko <mhocko@...nel.org>
>> Cc: Oscar Salvador <osalvador@...e.de>
>> Cc: "Rafael J. Wysocki" <rafael@...nel.org>
>> Cc: Baoquan He <bhe@...hat.com>
>> Cc: Wei Yang <richard.weiyang@...il.com>
>> Signed-off-by: David Hildenbrand <david@...hat.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

Powered by blists - more mailing lists