Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration
flat view
From: Alex Ghiti <alex@ghiti.fr>
Date: 2019-02-13 19:22:43
Also in:
linux-fsdevel, linux-mm, linux-riscv, linux-s390, linuxppc-dev, lkml
On 2/13/19 6:27 AM, Vlastimil Babka wrote:
On 1/17/19 7:39 PM, Alexandre Ghiti wrote:quoted
From: Alexandre Ghiti <alex@ghiti.fr> On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but that support gigantic pages, boottime reserved gigantic pages can not be freed at all. This patchs simply enables the possibility to hand back those pages to memory allocator. This commit then renames gigantic_page_supported and ARCH_HAS_GIGANTIC_PAGE to make them more accurate. Indeed, those values being false does not mean that the system cannot use gigantic pages: it just means that runtime allocation of gigantic pages is not supported, one can still allocate boottime gigantic pages if the architecture supports it. Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>I'm fine with the change, but wonder if this can be structured better in a way which would remove the duplicated "if (MEMORY_ISOLATION && COMPACTION) || CMA" from all arches, as well as the duplicated gigantic_page_runtime_allocation_supported()
Yeah, totally, we can factorize more than what I did. I prepared a v2 of this patch that does exactly that: remove the triplet from arch specific code and the duplicated gigantic_page_runtime_allocation_supported.
something like: - "select ARCH_HAS_GIGANTIC_PAGE" has no conditions, it just says the arch can support them either at boottime or runtime (but runtime is usable only if other conditions are met)
And the v2 gets rid of ARCH_HAS_GIGANTIC_PAGE totally since it is not needed by arch to advertise the fact they support gigantic page, actually, when selected, it really just means that an arch has the means to allocate runtime gigantic page: it is equivalent to (MEMORY_ISOLATION && COMPACTION) || CMA.
- gigantic_page_runtime_allocation_supported() is a function that returns true if ARCH_HAS_GIGANTIC_PAGE && ((MEMORY_ISOLATION && COMPACTION) || CMA) and there's a single instance, not per-arch. - code for freeing gigantic pages can probably still be conditional on ARCH_HAS_GIGANTIC_PAGE BTW I wanted also to do something about the "(MEMORY_ISOLATION && COMPACTION) || CMA" ugliness itself, i.e. put the common parts behind some new kconfig (COMPACTION_CORE ?) and expose it better to users, but I can take a stab on that once the above part is settled. Vlastimil
I send the v2 right away, if you can take a look Vlastimil, that would be great. Note that Andrew already picked this patch in its tree, I'm not sure how to proceed. Thanks for your remarks ! Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel