[PATCH v2 1/9] mm/hugetlb: remove checking hstate_is_gigantic() in return_unused_surplus_pages()

From: Naoya Horiguchi
Date: Thu Jun 23 2022 - 19:52:37 EST


From: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>

I found a weird state of 1GB hugepage pool, caused by the following
procedure:

- run a process reserving all free 1GB hugepages,
- shrink free 1GB hugepage pool to zero (i.e. writing 0 to
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages), then
- kill the reserving process.

, then all the hugepages are free *and* surplus at the same time.

$ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
3
$ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages
3
$ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/resv_hugepages
0
$ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/surplus_hugepages
3

This state is resolved by reserving and allocating the pages then
freeing them again, so this seems not to result in serious problem.
But it's a little surprizing (shrinking pool suddenly fails).

This behavior is caused by hstate_is_gigantic() check in
return_unused_surplus_pages(). This was introduced so long ago in 2008
by commit aa888a74977a ("hugetlb: support larger than MAX_ORDER"), and
it seems to me that this check is no longer unnecessary. Let's remove it.

Signed-off-by: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
---
mm/hugetlb.c | 4 ----
1 file changed, 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a57e1be41401..c538278170a2 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2432,10 +2432,6 @@ static void return_unused_surplus_pages(struct hstate *h,
/* Uncommit the reservation */
h->resv_huge_pages -= unused_resv_pages;

- /* Cannot return gigantic pages currently */
- if (hstate_is_gigantic(h))
- goto out;
-
/*
* Part (or even all) of the reservation could have been backed
* by pre-allocated pages. Only free surplus pages.
--
2.25.1