Thread (13 messages) 13 messages, 4 authors, 2019-03-06

Re: [PATCH v5 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

From: Dave Hansen <hidden>
Date: 2019-03-06 19:16:45
Also in: linux-arm-kernel, linux-mm, linux-s390, linux-sh, lkml, sparclinux

On 3/6/19 11:00 AM, Alexandre Ghiti wrote:
+static int set_max_huge_pages(struct hstate *h, unsigned long count,
+			      nodemask_t *nodes_allowed)
 {
 	unsigned long min_count, ret;
 
-	if (hstate_is_gigantic(h) && !gigantic_page_supported())
-		return h->max_huge_pages;
+	/*
+	 * Gigantic pages allocation depends on the capability for large page
+	 * range allocation. If the system cannot provide alloc_contig_range,
+	 * allow users to free gigantic pages.
+	 */
+	if (hstate_is_gigantic(h) && !IS_ENABLED(CONFIG_CONTIG_ALLOC)) {
+		spin_lock(&hugetlb_lock);
+		if (count > persistent_huge_pages(h)) {
+			spin_unlock(&hugetlb_lock);
+			return -EINVAL;
+		}
+		goto decrease_pool;
+	}
We talked about it during the last round and I don't seen any mention of
it here in comments or the changelog: Why is this a goto?  Why don't we
just let the code fall through to the "decrease_pool" label?  Why is
this new block needed at all?  Can't we just remove the old check and
let it be?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help