All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Yin, Fengwei" <fengwei.yin@intel.com>,
	Yu Zhao <yuzhao@google.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
	linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/6] mm: Introduce try_vma_alloc_zeroed_movable_folio()
Date: Fri, 17 Mar 2023 10:57:59 +0000	[thread overview]
Message-ID: <20230317105802.2634004-4-ryan.roberts@arm.com> (raw)
In-Reply-To: <20230317105802.2634004-1-ryan.roberts@arm.com>

Like vma_alloc_zeroed_movable_folio(), except it will opportunistically
attempt to allocate high-order folios, retrying with lower orders all
the way to order-0, until success. The user must check what they got
with folio_order().

This will be used to oportunistically allocate large folios for
anonymous memory with a sensible fallback under pressure.

For attempts to allocate non-0 orders, we set __GFP_NORETRY to prevent
high latency due to reclaim, instead preferring to just try for a lower
order. The same approach is used by the readahead code when allocating
large folios.

Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
---
 mm/memory.c | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 8798da968686..c9e09415ee18 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3024,6 +3024,27 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
 	count_vm_event(PGREUSE);
 }

+/*
+ * Opportunistically attempt to allocate high-order folios, retrying with lower
+ * orders all the way to order-0, until success. The user must check what they
+ * got with folio_order().
+ */
+static struct folio *try_vma_alloc_zeroed_movable_folio(
+						struct vm_area_struct *vma,
+						unsigned long vaddr, int order)
+{
+	struct folio *folio;
+	gfp_t gfp = __GFP_NORETRY | __GFP_NOWARN;
+
+	for (; order > 0; order--) {
+		folio = vma_alloc_zeroed_movable_folio(vma, vaddr, gfp, order);
+		if (folio)
+			return folio;
+	}
+
+	return vma_alloc_zeroed_movable_folio(vma, vaddr, 0, 0);
+}
+
 /*
  * Handle the case of a page which we actually need to copy to a new page,
  * either due to COW or unsharing.
@@ -3061,8 +3082,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
 		goto oom;

 	if (is_zero_pfn(pte_pfn(vmf->orig_pte))) {
-		new_folio = vma_alloc_zeroed_movable_folio(vma, vmf->address,
-									0, 0);
+		new_folio = try_vma_alloc_zeroed_movable_folio(vma,
+							vmf->address, 0);
 		if (!new_folio)
 			goto oom;
 	} else {
@@ -4050,7 +4071,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	/* Allocate our own private page. */
 	if (unlikely(anon_vma_prepare(vma)))
 		goto oom;
-	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address, 0, 0);
+	folio = try_vma_alloc_zeroed_movable_folio(vma, vmf->address, 0);
 	if (!folio)
 		goto oom;

--
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Ryan Roberts <ryan.roberts@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Yin, Fengwei" <fengwei.yin@intel.com>,
	Yu Zhao <yuzhao@google.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
	linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/6] mm: Introduce try_vma_alloc_zeroed_movable_folio()
Date: Fri, 17 Mar 2023 10:57:59 +0000	[thread overview]
Message-ID: <20230317105802.2634004-4-ryan.roberts@arm.com> (raw)
In-Reply-To: <20230317105802.2634004-1-ryan.roberts@arm.com>

Like vma_alloc_zeroed_movable_folio(), except it will opportunistically
attempt to allocate high-order folios, retrying with lower orders all
the way to order-0, until success. The user must check what they got
with folio_order().

This will be used to oportunistically allocate large folios for
anonymous memory with a sensible fallback under pressure.

For attempts to allocate non-0 orders, we set __GFP_NORETRY to prevent
high latency due to reclaim, instead preferring to just try for a lower
order. The same approach is used by the readahead code when allocating
large folios.

Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
---
 mm/memory.c | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 8798da968686..c9e09415ee18 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3024,6 +3024,27 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
 	count_vm_event(PGREUSE);
 }

+/*
+ * Opportunistically attempt to allocate high-order folios, retrying with lower
+ * orders all the way to order-0, until success. The user must check what they
+ * got with folio_order().
+ */
+static struct folio *try_vma_alloc_zeroed_movable_folio(
+						struct vm_area_struct *vma,
+						unsigned long vaddr, int order)
+{
+	struct folio *folio;
+	gfp_t gfp = __GFP_NORETRY | __GFP_NOWARN;
+
+	for (; order > 0; order--) {
+		folio = vma_alloc_zeroed_movable_folio(vma, vaddr, gfp, order);
+		if (folio)
+			return folio;
+	}
+
+	return vma_alloc_zeroed_movable_folio(vma, vaddr, 0, 0);
+}
+
 /*
  * Handle the case of a page which we actually need to copy to a new page,
  * either due to COW or unsharing.
@@ -3061,8 +3082,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
 		goto oom;

 	if (is_zero_pfn(pte_pfn(vmf->orig_pte))) {
-		new_folio = vma_alloc_zeroed_movable_folio(vma, vmf->address,
-									0, 0);
+		new_folio = try_vma_alloc_zeroed_movable_folio(vma,
+							vmf->address, 0);
 		if (!new_folio)
 			goto oom;
 	} else {
@@ -4050,7 +4071,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	/* Allocate our own private page. */
 	if (unlikely(anon_vma_prepare(vma)))
 		goto oom;
-	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address, 0, 0);
+	folio = try_vma_alloc_zeroed_movable_folio(vma, vmf->address, 0);
 	if (!folio)
 		goto oom;

--
2.25.1



  parent reply	other threads:[~2023-03-17 10:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 10:57 [RFC PATCH 0/6] variable-order, large folios for anonymous memory Ryan Roberts
2023-03-17 10:57 ` Ryan Roberts
2023-03-17 10:57 ` [RFC PATCH 1/6] mm: Expose clear_huge_page() unconditionally Ryan Roberts
2023-03-17 10:57   ` Ryan Roberts
2023-03-17 10:57 ` [RFC PATCH 2/6] mm: pass gfp flags and order to vma_alloc_zeroed_movable_folio() Ryan Roberts
2023-03-17 10:57   ` Ryan Roberts
2023-03-17 10:57 ` Ryan Roberts [this message]
2023-03-17 10:57   ` [RFC PATCH 3/6] mm: Introduce try_vma_alloc_zeroed_movable_folio() Ryan Roberts
2023-03-17 10:58 ` [RFC PATCH 4/6] mm: Implement folio_add_new_anon_rmap_range() Ryan Roberts
2023-03-17 10:58   ` Ryan Roberts
2023-03-22  6:59   ` Yin Fengwei
2023-03-22  6:59     ` Yin Fengwei
2023-03-22  7:10   ` Yin Fengwei
2023-03-22  7:10     ` Yin Fengwei
2023-03-22  7:42     ` Ryan Roberts
2023-03-22  7:42       ` Ryan Roberts
2023-03-17 10:58 ` [RFC PATCH 5/6] mm: Allocate large folios for anonymous memory Ryan Roberts
2023-03-17 10:58   ` Ryan Roberts
2023-03-17 10:58 ` [RFC PATCH 6/6] WORKAROUND: Don't split large folios on madvise Ryan Roberts
2023-03-17 10:58   ` Ryan Roberts
2023-03-22  8:19   ` Yin Fengwei
2023-03-22  8:19     ` Yin Fengwei
2023-03-22  8:59     ` Ryan Roberts
2023-03-22  8:59       ` Ryan Roberts
2023-03-22 12:03 ` [RFC PATCH 0/6] variable-order, large folios for anonymous memory Ryan Roberts
2023-03-22 12:03   ` Ryan Roberts
2023-03-22 13:36   ` Yin, Fengwei
2023-03-22 13:36     ` Yin, Fengwei
2023-03-22 14:25     ` Ryan Roberts
2023-03-22 14:25       ` Ryan Roberts

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=20230317105802.2634004-4-ryan.roberts@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=fengwei.yin@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.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 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.