All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sidhartha Kumar <sidhartha.kumar@oracle.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, songmuchun@bytedance.com,
	mike.kravetz@oracle.com, willy@infradead.org,
	tsahu@linux.ibm.com, jhubbard@nvidia.com,
	Sidhartha Kumar <sidhartha.kumar@oracle.com>
Subject: [PATCH mm-unstable 4/8] mm/hugetlb: convert alloc_surplus_huge_page() to folios
Date: Tue,  3 Jan 2023 13:13:36 -0600	[thread overview]
Message-ID: <20230103191340.116536-5-sidhartha.kumar@oracle.com> (raw)
In-Reply-To: <20230103191340.116536-1-sidhartha.kumar@oracle.com>

Change alloc_surplus_huge_page() to alloc_surplus_hugetlb_folio() and
update its callers.

Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
---
 mm/hugetlb.c | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8dffb77d3510..0b8bab52bc7e 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2237,8 +2237,8 @@ int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
 /*
  * Allocates a fresh surplus page from the page allocator.
  */
-static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
-						int nid, nodemask_t *nmask)
+static struct folio *alloc_surplus_hugetlb_folio(struct hstate *h,
+				gfp_t gfp_mask,	int nid, nodemask_t *nmask)
 {
 	struct folio *folio = NULL;
 
@@ -2275,7 +2275,7 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
 out_unlock:
 	spin_unlock_irq(&hugetlb_lock);
 
-	return &folio->page;
+	return folio;
 }
 
 static struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
@@ -2308,7 +2308,7 @@ static
 struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
 		struct vm_area_struct *vma, unsigned long addr)
 {
-	struct page *page = NULL;
+	struct folio *folio = NULL;
 	struct mempolicy *mpol;
 	gfp_t gfp_mask = htlb_alloc_mask(h);
 	int nid;
@@ -2319,16 +2319,16 @@ struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
 		gfp_t gfp = gfp_mask | __GFP_NOWARN;
 
 		gfp &=  ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
-		page = alloc_surplus_huge_page(h, gfp, nid, nodemask);
+		folio = alloc_surplus_hugetlb_folio(h, gfp, nid, nodemask);
 
 		/* Fallback to all nodes if page==NULL */
 		nodemask = NULL;
 	}
 
-	if (!page)
-		page = alloc_surplus_huge_page(h, gfp_mask, nid, nodemask);
+	if (!folio)
+		folio = alloc_surplus_hugetlb_folio(h, gfp_mask, nid, nodemask);
 	mpol_cond_put(mpol);
-	return page;
+	return &folio->page;
 }
 
 /* page migration callback function */
@@ -2377,6 +2377,7 @@ static int gather_surplus_pages(struct hstate *h, long delta)
 	__must_hold(&hugetlb_lock)
 {
 	LIST_HEAD(surplus_list);
+	struct folio *folio;
 	struct page *page, *tmp;
 	int ret;
 	long i;
@@ -2396,13 +2397,13 @@ static int gather_surplus_pages(struct hstate *h, long delta)
 retry:
 	spin_unlock_irq(&hugetlb_lock);
 	for (i = 0; i < needed; i++) {
-		page = alloc_surplus_huge_page(h, htlb_alloc_mask(h),
+		folio = alloc_surplus_hugetlb_folio(h, htlb_alloc_mask(h),
 				NUMA_NO_NODE, NULL);
-		if (!page) {
+		if (!folio) {
 			alloc_ok = false;
 			break;
 		}
-		list_add(&page->lru, &surplus_list);
+		list_add(&folio->lru, &surplus_list);
 		cond_resched();
 	}
 	allocated += i;
@@ -3355,7 +3356,7 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
 	 * First take pages out of surplus state.  Then make up the
 	 * remaining difference by allocating fresh huge pages.
 	 *
-	 * We might race with alloc_surplus_huge_page() here and be unable
+	 * We might race with alloc_surplus_hugetlb_folio() here and be unable
 	 * to convert a surplus huge page to a normal huge page. That is
 	 * not critical, though, it just means the overall size of the
 	 * pool might be one hugepage larger than it needs to be, but
@@ -3398,7 +3399,7 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
 	 * By placing pages into the surplus state independent of the
 	 * overcommit value, we are allowing the surplus pool size to
 	 * exceed overcommit. There are few sane options here. Since
-	 * alloc_surplus_huge_page() is checking the global counter,
+	 * alloc_surplus_hugetlb_folio() is checking the global counter,
 	 * though, we'll note that we're not allowed to exceed surplus
 	 * and won't grow the pool anywhere else. Not until one of the
 	 * sysctls are changed, or the surplus pages go out of use.
-- 
2.39.0


  parent reply	other threads:[~2023-01-03 19:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03 19:13 [PATCH mm-unstable 0/9] continue hugetlb folio conversions Sidhartha Kumar
2023-01-03 19:13 ` [PATCH mm-unstable 1/8] mm/hugetlb: convert isolate_hugetlb to folios Sidhartha Kumar
2023-01-03 20:56   ` Matthew Wilcox
2023-01-06 23:04   ` Mike Kravetz
2023-01-03 19:13 ` [PATCH mm-unstable 2/8] mm/hugetlb: convert __update_and_free_page() " Sidhartha Kumar
2023-01-06 23:46   ` Mike Kravetz
2023-01-03 19:13 ` [PATCH mm-unstable 3/8] mm/hugetlb: convert dequeue_hugetlb_page_node functions " Sidhartha Kumar
2023-01-03 21:00   ` Matthew Wilcox
2023-01-06 23:57     ` Mike Kravetz
2023-01-03 19:13 ` Sidhartha Kumar [this message]
2023-01-07  0:15   ` [PATCH mm-unstable 4/8] mm/hugetlb: convert alloc_surplus_huge_page() " Mike Kravetz
2023-01-03 19:13 ` [PATCH mm-unstable 5/8] mm/hugetlb: increase use of folios in alloc_huge_page() Sidhartha Kumar
2023-01-07  0:30   ` Mike Kravetz
2023-01-03 19:13 ` [PATCH mm-unstable 6/8] mm/hugetlb: convert alloc_migrate_huge_page to folios Sidhartha Kumar
2023-01-07  0:54   ` Mike Kravetz
2023-01-09 16:26     ` Sidhartha Kumar
2023-01-09 18:21       ` Mike Kravetz
2023-01-03 19:13 ` [PATCH mm-unstable 7/8] mm/hugetlb: convert restore_reserve_on_error() " Sidhartha Kumar
2023-01-07  0:57   ` Mike Kravetz
2023-01-03 19:13 ` [PATCH mm-unstable 8/8] mm/hugetlb: convert demote_free_huge_page " Sidhartha Kumar
2023-01-07  1:11   ` Mike Kravetz
2023-01-07  1:31     ` Matthew Wilcox
2023-01-07 20:55       ` Mike Kravetz
2023-01-09 16:36         ` Sidhartha Kumar
2023-01-09 18:23           ` Mike Kravetz
2023-01-09 20:01             ` John Hubbard
2023-01-09 20:53               ` Sidhartha Kumar

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=20230103191340.116536-5-sidhartha.kumar@oracle.com \
    --to=sidhartha.kumar@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=songmuchun@bytedance.com \
    --cc=tsahu@linux.ibm.com \
    --cc=willy@infradead.org \
    /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 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.