Re: [PATCH 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug

From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Oscar Salvador <osalvador@suse.de>,
	akpm@linux-foundation.org, dan.j.williams@intel.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug
Date: Fri, 5 Apr 2019 10:05:09 +0200	[thread overview]
Message-ID: <a4230528-dc7e-e17c-c363-e3da7961dbf1@redhat.com> (raw)
In-Reply-To: <20190405071418.GN12864@dhcp22.suse.cz>

On 05.04.19 09:14, Michal Hocko wrote:
> On Thu 04-04-19 20:27:41, David Hildenbrand wrote:
>> On 04.04.19 20:01, Oscar Salvador wrote:
> [...]
>>> But I am not really convinced by MHP_SYSTEM_RAM name, and I think we should stick
>>> with MHP_MEMBLOCK_API because it represents __what__ is that flag about and its
>>> function, e.g: create memory block devices.
> 
> Exactly

Fine with me for keeping what Oscar has.

> 
>> This nicely aligns with the sub-section memory add support discussion.
>>
>> MHP_MEMBLOCK_API immediately implies that
>>
>> - memory is used as system ram. Memory can be onlined/offlined. Markers
>>   at sections indicate if the section is online/offline.
> 
> No there is no implication like that. It means only that the onlined
> memory has a sysfs interface. Nothing more, nothing less

As soon as there is a online/offline interface, you *can* (and user
space usually *will*) online that memory. Onlining/offlining is only
defined for memory to be added to the buddy - memory to be used as
"system ram". Doing it for random device memory will not work / result
in undefined behavior.

Not adding memory block devices for system ram will not allow user space
to online/offline it and break kdump reload for hot-added memory. But
memory can be onlined/offlined using internal APIs of course - if that's
what you were referring to.

> 
> This is an internal API so we are not carving anything into the stone.

That is true.

> So can we simply start with what we have and go from there?

Sure, what Oscar does here is just a simple refactoring of the interface
and I was just wondering if the interface needs a general overhaul.

>I am getting
> felling that this discussion just makes the whole thing more muddy.

I think this discussion is helpful to understand how the whole thing is
supposed to work :) At least on my side.

Meanwhile, I will have a look if memory block devices cannot simply be
created by the caller of arch_add_memory(). At least it feels like
creating memory bock devices could be factored out - I remember that it
was not that easy.

-- 

Thanks,

David / dhildenb