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

[David Hildenbrand]

On 04.04.19 12:04, Oscar Salvador wrote:
> On Wed, Apr 03, 2019 at 10:46:03AM +0200, Michal Hocko wrote:
>> On Thu 28-03-19 14:43:18, Oscar Salvador wrote:
>>> From: Michal Hocko <mhocko@xxxxxxxx>
>>>
>>> arch_add_memory, __add_pages take a want_memblock which controls whether
>>> the newly added memory should get the sysfs memblock user API (e.g.
>>> ZONE_DEVICE users do not want/need this interface). Some callers even
>>> want to control where do we allocate the memmap from by configuring
>>> altmap.
>>>
>>> Add a more generic hotplug context for arch_add_memory and __add_pages.
>>> struct mhp_restrictions contains flags which contains additional
>>> features to be enabled by the memory hotplug (MHP_MEMBLOCK_API
>>> currently) and altmap for alternative memmap allocator.
>>>
>>> Please note that the complete altmap propagation down to vmemmap code
>>> is still not done in this patch. It will be done in the follow up to
>>> reduce the churn here.
>>>
>>> This patch shouldn't introduce any functional change.
>>
>> Is there an agreement on the interface here? Or do we want to hide almap
>> behind some more general looking interface? If the former is true, can
>> we merge it as it touches a code that might cause merge conflicts later on
>> as multiple people are working on this area.
> 
> Uhm, I think that the interface is fine for now.
> I thought about providing some callbacks to build the altmap layout, but I
> realized that it was overcomplicated and I would rather start easy.
> Maybe the naming could be changed to what David suggested, something like
> "mhp_options", which actually looks more generic and allows us to stuff more
> things into it should the need arise in the future.
> But that is something that can come afterwards I guess.

I'd vote to rename it right away, but feel free to continue how you prefer.

-- 

Thanks,

David / dhildenb