From: Jinjiang Tu <tujinjiang@huawei.com>
To: <akpm@linux-foundation.org>, <muchun.song@linux.dev>,
<david@redhat.com>, <osalvador@suse.de>
Cc: <linux-mm@kvack.org>, <wangkefeng.wang@huawei.com>,
<sunnanyong@huawei.com>, <tujinjiang@huawei.com>
Subject: [PATCH] mm/hugetlb: fix surplus pages in dissolve_free_huge_page()
Date: Mon, 3 Mar 2025 14:09:19 +0800 [thread overview]
Message-ID: <20250303060920.2886263-1-tujinjiang@huawei.com> (raw)
In dissolve_free_huge_page(), free huge pages are dissolved without
adjusting surplus count. However, free huge pages may be accounted as
surplus pages, and will lead to wrong surplus count.
Steps to reproduce:
1) create 64 huge pages for node1
2) run a program to reserve (don't consume) all the huge pages
3) echo 0 > nr_huge_pages for node1. After this step, free huge pages in
Node1 are surplus.
4) create 80 huge pages for node0
5) offline memory of node1 and kill the program in step 2)
The result:
Node0 Node1
total 80 0
free 80 0
surplus 0 61
To fix it, adjust surplus when destroying huge pages if the node has
surplus pages in dissolve_free_hugetlb_folio().
The result with this patch:
Node0 Node1
total 80 0
free 80 0
surplus 0 0
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
---
mm/hugetlb.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 163190e89ea1..2a24ade9d157 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2135,6 +2135,8 @@ int dissolve_free_hugetlb_folio(struct folio *folio)
if (!folio_ref_count(folio)) {
struct hstate *h = folio_hstate(folio);
+ bool adjust_surplus = false;
+
if (!available_huge_pages(h))
goto out;
@@ -2157,7 +2159,9 @@ int dissolve_free_hugetlb_folio(struct folio *folio)
goto retry;
}
- remove_hugetlb_folio(h, folio, false);
+ if (h->surplus_huge_pages_node[folio_nid(folio)])
+ adjust_surplus = true;
+ remove_hugetlb_folio(h, folio, adjust_surplus);
h->max_huge_pages--;
spin_unlock_irq(&hugetlb_lock);
@@ -2177,7 +2181,7 @@ int dissolve_free_hugetlb_folio(struct folio *folio)
rc = hugetlb_vmemmap_restore_folio(h, folio);
if (rc) {
spin_lock_irq(&hugetlb_lock);
- add_hugetlb_folio(h, folio, false);
+ add_hugetlb_folio(h, folio, adjust_surplus);
h->max_huge_pages++;
goto out;
}
--
2.43.0
next reply other threads:[~2025-03-03 6:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 6:09 Jinjiang Tu [this message]
2025-03-03 10:25 ` David Hildenbrand
2025-03-03 11:16 ` Jinjiang Tu
2025-03-03 11:23 ` Jinjiang Tu
2025-03-03 11:47 ` David Hildenbrand
2025-03-03 12:10 ` Jinjiang Tu
2025-03-03 13:45 ` David Hildenbrand
2025-03-04 3:50 ` Jinjiang Tu
2025-03-04 10:15 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250303060920.2886263-1-tujinjiang@huawei.com \
--to=tujinjiang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=sunnanyong@huawei.com \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox