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
