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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
