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
