On Thu, Apr 04, 2019 at 12:31:15PM +0200, Michal Hocko wrote: > On Thu 04-04-19 12:04:05, 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. > > > > But merging this now is not a bad idea taking into account that some people > > is working on the same area and merge conflicts arise easily. > > Otherwise re-working it every version is going to be a pita. > > I do not get wee bit about naming TBH. Do as you like. But please repost > just these two patches and we can discuss the rest of this feature in a > separate discussion. Sure, I will repost them in the next hour (just want to check that everything is alright). -- Oscar Salvador SUSE L3
