Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration
flat view
From: Mike Kravetz <hidden>
Date: 2019-01-17 20:09:11
Also in:
linux-arm-kernel, linux-fsdevel, linux-mm, linux-riscv, linux-s390, lkml
On 1/17/19 10:39 AM, Alexandre Ghiti wrote:
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>
Thank you for doing this! Reviewed-by: Mike Kravetz <redacted>
quoted hunk ↗ jump to hunk
--- a/include/linux/gfp.h +++ b/include/linux/gfp.h@@ -589,8 +589,8 @@ static inline bool pm_suspended_storage(void) /* The below functions must be run on a range from a single zone. */ extern int alloc_contig_range(unsigned long start, unsigned long end, unsigned migratetype, gfp_t gfp_mask); -extern void free_contig_range(unsigned long pfn, unsigned nr_pages); #endif +extern void free_contig_range(unsigned long pfn, unsigned int nr_pages);
I think nr_pages should be an unsigned long in cma_release() and here as well, but that is beyond the scope of this patch. Most callers of cma_release pass in a truncated unsigned long. The truncation is unlikely to cause any issues, just would be nice if types were consistent. I have a patch to do that as part of a contiguous allocation series that I will get back to someday.
quoted hunk ↗ jump to hunk
@@ -2350,9 +2355,10 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count, break; } out: - ret = persistent_huge_pages(h); + h->max_huge_pages = persistent_huge_pages(h); spin_unlock(&hugetlb_lock); - return ret; + + return 0; } #define HSTATE_ATTR_RO(_name) \@@ -2404,11 +2410,6 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, int err; NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY); - if (hstate_is_gigantic(h) && !gigantic_page_supported()) { - err = -EINVAL; - goto out; - } - if (nid == NUMA_NO_NODE) { /* * global hstate attribute@@ -2428,7 +2429,9 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, } else nodes_allowed = &node_states[N_MEMORY]; - h->max_huge_pages = set_max_huge_pages(h, count, nodes_allowed); + err = set_max_huge_pages(h, count, nodes_allowed); + if (err) + goto out; if (nodes_allowed != &node_states[N_MEMORY]) NODEMASK_FREE(nodes_allowed);
Yeah! Those changes causes max_huge_pages to be modified while holding hugetlb_lock as it should be. -- Mike Kravetz