Messages in this thread | | | Subject | Re: [RFC PATCH 2/2] mm,page_alloc: Make alloc_contig_range handle free hugetlb pages | From | David Hildenbrand <> | Date | Wed, 10 Feb 2021 15:36:41 +0100 |
| |
On 10.02.21 15:24, Oscar Salvador wrote: > On Wed, Feb 10, 2021 at 09:23:59AM +0100, David Hildenbrand wrote: >> On 08.02.21 11:38, Oscar Salvador wrote: >>> Free hugetlb pages are trickier to handle as to in order to guarantee >>> no userspace appplication disruption, we need to replace the >>> current free hugepage with a new one. >>> >>> In order to do that, a new function called alloc_and_dissolve_huge_page >>> in introduced. >>> This function will first try to get a new fresh hugetlb page, and if it >>> succeeds, it will dissolve the old one. >>> >> >> Thanks for looking into this! Can we move this patch to #1 in the series? It >> is the easier case. >> >> I also wonder if we should at least try on the memory unplug path to keep >> nr_pages by at least trying to allocate at new one if required, and printing >> a warning if that fails (after all, we're messing with something configured >> by the admin - "nr_pages"). Note that gigantic pages are special (below). > > So, do you mean to allocate a new fresh hugepage in case we have a free > hugetlb page within the range we are trying to offline? That makes some > sense I guess. > > I can have a look at that, and make hotplug code use the new > alloc_and_dissolve().
Yes, with the difference that hotplug code most probably wants to continue even if allocation failed (printing a warning) - mimix existing behavior. For alloc_contig, I'd say, fail if we cannot "relocate free huge pages that are still required to no modify nr_pages".
alloc_and_dissolve() should only allocate a page if really required (e.g., not sure if we could skip allocation in some cases - like with surplus pages, needs some investigation), such that the admin-configured nr_pages stays unchanged.
-- Thanks,
David / dhildenb
| |