Re: [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory

[Michal Hocko]

On Mon 31-07-17 14:35:21, Gerald Schaefer wrote:
> On Fri, 28 Jul 2017 14:19:41 +0200
> Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> 
> > On Thu 27-07-17 08:56:52, Michal Hocko wrote:
> > > On Wed 26-07-17 17:06:59, Jerome Glisse wrote:
> > > [...]
> > > > This does not seems to be an opt-in change ie if i am reading patch 3
> > > > correctly if an altmap is not provided to __add_pages() you fallback
> > > > to allocating from begining of zone. This will not work with HMM ie
> > > > device private memory. So at very least i would like to see some way
> > > > to opt-out of this. Maybe a new argument like bool forbid_altmap ?
> > > 
> > > OK, I see! I will think about how to make a sane api for that.
> > 
> > This is what I came up with. s390 guys mentioned that I cannot simply
> > use the new range at this stage yet. This will need probably some other
> > changes but I guess we want an opt-in approach with an arch veto in general.
> > 
> > So what do you think about the following? Only x86 is update now and I
> > will split it into two parts but the idea should be clear at least.
> 
> This looks good, and the kernel will also boot again on s390 when applied
> on top of the other 5 patches (plus adding the s390 part here).

Thanks for testing Gerald! I am still undecided whether the arch code
should veto MHP_RANGE_ACCESSIBLE if it cannot be supported or just set
it when it is supported. My last post did the later but the first one
sounds like a more clear API to me. I will keep thinking about it.

Anyway, did you have any chance to consider mapping the new physical
memory range inside arch_add_memory rather than during online on s390?
-- 
Michal Hocko
SUSE Labs