[lkml]   [2019]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug
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 <>
> >
> > 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.

Oscar Salvador

 \ /
  Last update: 2019-04-04 12:04    [W:0.072 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site