Re: [PATCH v13 05/12] mm: hugetlb: allocate the vmemmap pages associated with each HugeTLB page

[David Hildenbrand]

On 26.01.21 15:58, Oscar Salvador wrote:
> On Tue, Jan 26, 2021 at 10:36:21AM +0100, David Hildenbrand wrote:
> > I think either keep it completely simple (only free vmemmap of hugetlb
> > pages allocated early during boot - which is what's not sufficient for
> > some use cases) or implement the full thing properly (meaning, solve
> > most challenging issues to get the basics running).
> >
> > I don't want to have some easy parts of complex features merged (e.g.,
> > breaking other stuff as you indicate below), and later finding out "it's
> > not that easy" again and being stuck with it forever.
>
> Well, we could try to do an optimistic allocation, without tricky loopings.
> If that fails, refuse to shrink the pool at that moment.
>
> The user could always try to shrink it later via /proc/sys/vm/nr_hugepages
> interface.
>
> But I am just thinking out loud..

The real issue seems to be discarding the vmemmap on any memory that has 
movability constraints - CMA and ZONE_MOVABLE; otherwise, as discussed, 
we can reuse parts of the thingy we're freeing for the vmemmap. Not that 
it would be ideal: that once-a-huge-page thing will never ever be a huge 
page again - but if it helps with OOM in corner cases, sure.

Possible simplification: don't perform the optimization for now with 
free huge pages residing on ZONE_MOVABLE or CMA. Certainly not perfect: 
what happens when migrating a huge page from ZONE_NORMAL to 
(ZONE_MOVABLE|CMA)?

> > > Of course, this means that e.g: memory-hotplug (hot-remove) will not fully work
> > > when this in place, but well.
> >
> > Can you elaborate? Are we're talking about having hugepages in
> > ZONE_MOVABLE that are not migratable (and/or dissolvable) anymore? Than
> > a clear NACK from my side.
>
> Pretty much, yeah.

Note that we most likely soon have to tackle migrating/dissolving (free) 
hugetlbfs pages from alloc_contig_range() context - e.g., for CMA 
allocations. That's certainly something to keep in mind regarding any 
approaches that already break offline_pages().

--
Thanks,

David / dhildenb