All of lore.kernel.org
 help / color / mirror / Atom feed
* [merged mm-stable] mm-hugeltb-fix-nodes-huge-page-allocation-when-there-are-surplus-pages.patch removed from -mm tree
@ 2023-10-04 20:17 Andrew Morton
  0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2023-10-04 20:17 UTC (permalink / raw)
  To: mm-commits, muchun.song, mike.kravetz, mel, lee.schermerhorn,
	andi, xueshi.hu, akpm


The quilt patch titled
     Subject: mm/hugetlb: fix nodes huge page allocation when there are surplus pages
has been removed from the -mm tree.  Its filename was
     mm-hugeltb-fix-nodes-huge-page-allocation-when-there-are-surplus-pages.patch

This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

------------------------------------------------------
From: Xueshi Hu <xueshi.hu@smartx.com>
Subject: mm/hugetlb: fix nodes huge page allocation when there are surplus pages
Date: Tue, 29 Aug 2023 11:33:43 +0800

In set_nr_huge_pages(), local variable "count" is used to record
persistent_huge_pages(), but when it cames to nodes huge page allocation,
the semantics changes to nr_huge_pages.  When there exists surplus huge
pages and using the interface under
/sys/devices/system/node/node*/hugepages to change huge page pool size,
this difference can result in the allocation of an unexpected number of
huge pages.

Steps to reproduce the bug:

Starting with:

				  Node 0          Node 1    Total
	HugePages_Total             0.00            0.00     0.00
	HugePages_Free              0.00            0.00     0.00
	HugePages_Surp              0.00            0.00     0.00

create 100 huge pages in Node 0 and consume it, then set Node 0 's
nr_hugepages to 0.

yields:

				  Node 0          Node 1    Total
	HugePages_Total           200.00            0.00   200.00
	HugePages_Free              0.00            0.00     0.00
	HugePages_Surp            200.00            0.00   200.00

write 100 to Node 1's nr_hugepages

		echo 100 > /sys/devices/system/node/node1/\
	hugepages/hugepages-2048kB/nr_hugepages

gets:

				  Node 0          Node 1    Total
	HugePages_Total           200.00          400.00   600.00
	HugePages_Free              0.00          400.00   400.00
	HugePages_Surp            200.00            0.00   200.00

Kernel is expected to create only 100 huge pages and it gives 200.

Link: https://lkml.kernel.org/r/20230829033343.467779-1-xueshi.hu@smartx.com
Fixes: 9a30523066cd ("hugetlb: add per node hstate attributes")
Signed-off-by: Xueshi Hu <xueshi.hu@smartx.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/hugetlb.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/mm/hugetlb.c~mm-hugeltb-fix-nodes-huge-page-allocation-when-there-are-surplus-pages
+++ a/mm/hugetlb.c
@@ -3457,7 +3457,9 @@ static int set_max_huge_pages(struct hst
 	if (nid != NUMA_NO_NODE) {
 		unsigned long old_count = count;
 
-		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
+		count += persistent_huge_pages(h) -
+			 (h->nr_huge_pages_node[nid] -
+			  h->surplus_huge_pages_node[nid]);
 		/*
 		 * User may have specified a large count value which caused the
 		 * above calculation to overflow.  In this case, they wanted
_

Patches currently in -mm which might be from xueshi.hu@smartx.com are



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-10-04 20:17 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-04 20:17 [merged mm-stable] mm-hugeltb-fix-nodes-huge-page-allocation-when-there-are-surplus-pages.patch removed from -mm tree Andrew Morton

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.