Thread (13 messages) flat view 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 21:17:37
Also in: linux-arm-kernel, linux-mm, linux-s390, linux-sh, lkml, sparclinux

On 3/6/19 12:08 PM, Alex Ghiti wrote:
quoted
quoted
+    /*
+     * 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?
I'll get rid of the goto, I don't know how to justify it properly in a
comment,
maybe because it is not necessary.
This is not a new block, this means exactly the same as before (remember
gigantic_page_supported() actually meant CONTIG_ALLOC before this series),
except that now we allow a user to free boottime allocated gigantic pages.
And no we cannot just remove the check and let it be since it would modify
the current behaviour, which is to return an error when trying to allocate
gigantic pages whereas alloc_contig_range is not defined. I thought it was
clearly commented above, I can try to make it more explicit.
OK, that makes sense.  Could you get some of this in the changelog,
please?  Otherwise this all looks good to me.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help