From: Shivank Garg <shivankg@amd.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Ankur Arora <ankur.a.arora@oracle.com>,
Pedro Falcato <pfalcato@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>, Bharata B Rao <bharata@amd.com>,
Hrushikesh Salunke <hsalunke@amd.com>,
K Prateek Nayak <kprateek.nayak@amd.com>
Cc: <x86@kernel.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Shivank Garg <shivankg@amd.com>
Subject: [PATCH RFC] mm/memory: drop PROCESS_PAGES_NON_PREEMPT_BATCH
Date: Thu, 22 Oct 2026 08:14:30 +0000 [thread overview]
Message-ID: <20261022-clear-pages-batch-v1-1-13d3bd0b876e@amd.com> (raw)
clear_contig_highpages() clears the whole range at once under
preemptible models. Otherwise it clears PROCESS_PAGES_NON_PREEMPT_BATCH
pages at a time, with a cond_resched() in between. The batch is 32MB if
the architecture defines clear_pages(), and one page otherwise.
Since commit 7dadeaa6e851 ("sched: Further restrict the preemption
modes"), architectures that support lazy preemption only offer the
full, lazy and RT preemption models, also with PREEMPT_DYNAMIC. x86 is
one of them, and it is the only architecture that defines
clear_pages(). So the 32MB batch is never used: whenever
clear_contig_highpages() runs under a cooperative model, the batch is
one page.
Make that explicit. Clear the whole range when CONFIG_PREEMPTION is
set, and one page at a time with cond_resched() in between otherwise.
Drop PROCESS_PAGES_NON_PREEMPT_BATCH, which has no other users.
PREEMPT_DYNAMIC kernels also have CONFIG_PREEMPTION set, and
cond_resched() does nothing on any of these kernels. So a build-time
CONFIG_PREEMPTION check is enough, and preempt_model_preemptible() is
not needed.
No functional change intended.
Suggested-by: David Hildenbrand <david@kernel.org>
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
This came up in review of the copy_mc_highpages() series [1]. Pedro
pointed out that most architecture are full or lazy preempt, so mm does
not need to check the preemption model at runtime or batch the copy for
cond_resched(), and simple per-page fallback is enough for non-preemptible
models. David suggested doing the same for the zeroing path, and
this patch does that.
[1] https://lore.kernel.org/all/20261019-batpagecopy-v2-1-d75e7d0dfaae@amd.com
---
include/linux/mm.h | 28 +---------------------------
mm/memory.c | 29 ++++++++++++++++-------------
2 files changed, 17 insertions(+), 40 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 35f5fc43861a..1083d0645d63 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -5269,7 +5269,7 @@ static inline void clear_page_guard(struct zone *zone, struct page *page,
*
* When running under preemptible models this is not a problem. Under
* cooperatively scheduled models, however, the caller is expected to
- * limit @npages to no more than PROCESS_PAGES_NON_PREEMPT_BATCH.
+ * clear one page at a time and call cond_resched() in between.
*/
static inline void clear_pages(void *addr, unsigned int npages)
{
@@ -5280,32 +5280,6 @@ static inline void clear_pages(void *addr, unsigned int npages)
}
#endif
-#ifndef PROCESS_PAGES_NON_PREEMPT_BATCH
-#ifdef clear_pages
-/*
- * The architecture defines clear_pages(), and we assume that it is
- * generally "fast". So choose a batch size large enough to allow the processor
- * headroom for optimizing the operation and yet small enough that we see
- * reasonable preemption latency for when this optimization is not possible
- * (ex. slow microarchitectures, memory bandwidth saturation.)
- *
- * With a value of 32MB and assuming a memory bandwidth of ~10GBps, this should
- * result in worst case preemption latency of around 3ms when clearing pages.
- *
- * (See comment above clear_pages() for why preemption latency is a concern
- * here.)
- */
-#define PROCESS_PAGES_NON_PREEMPT_BATCH (SZ_32M >> PAGE_SHIFT)
-#else /* !clear_pages */
-/*
- * The architecture does not provide a clear_pages() implementation. Assume
- * that clear_page() -- which clear_pages() will fallback to -- is relatively
- * slow and choose a small value for PROCESS_PAGES_NON_PREEMPT_BATCH.
- */
-#define PROCESS_PAGES_NON_PREEMPT_BATCH 1
-#endif
-#endif
-
#ifdef __HAVE_ARCH_GATE_AREA
extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm);
extern int in_gate_area_no_mm(unsigned long addr);
diff --git a/mm/memory.c b/mm/memory.c
index 976cd03954e3..e09a53ea5943 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -7654,27 +7654,30 @@ static inline int process_huge_page(
}
static void clear_contig_highpages(struct page *page, unsigned long addr,
- unsigned int nr_pages)
+ unsigned int nr_pages)
{
- unsigned int i, count;
+ unsigned int i;
+
+ might_sleep();
+
/*
* When clearing we want to operate on the largest extent possible to
* allow for architecture specific extent based optimizations.
*
- * However, since clear_user_highpages() (and primitives clear_user_pages(),
- * clear_pages()), do not call cond_resched(), limit the unit size when
- * running under non-preemptible scheduling models.
+ * clear_user_highpages() (and primitives clear_user_pages(),
+ * clear_pages()) do not call cond_resched(). That is fine on
+ * preemptible kernels, where the scheduler can preempt the clearing
+ * at any point, so clear the whole range at once. Otherwise, clear
+ * one page at a time and reschedule in between.
*/
- const unsigned int unit = preempt_model_preemptible() ?
- nr_pages : PROCESS_PAGES_NON_PREEMPT_BATCH;
-
- might_sleep();
+ if (IS_ENABLED(CONFIG_PREEMPTION)) {
+ clear_user_highpages(page, addr, nr_pages);
+ return;
+ }
- for (i = 0; i < nr_pages; i += count) {
+ for (i = 0; i < nr_pages; i++) {
cond_resched();
-
- count = min(unit, nr_pages - i);
- clear_user_highpages(page + i, addr + i * PAGE_SIZE, count);
+ clear_user_highpages(page + i, addr + i * PAGE_SIZE, 1);
}
}
---
base-commit: fcec4f4bcc1101dbd7e3aff267856b3bbfe128c6
change-id: 20261021-clear-pages-batch-77f72ef808e4
Best regards,
--
Shivank Garg <shivankg@amd.com>
next reply other threads:[~2026-10-22 8:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 8:14 Shivank Garg [this message]
2026-10-22 9:58 ` Pedro Falcato
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=20261022-clear-pages-batch-v1-1-13d3bd0b876e@amd.com \
--to=shivankg@amd.com \
--cc=akpm@linux-foundation.org \
--cc=ankur.a.arora@oracle.com \
--cc=bharata@amd.com \
--cc=bp@alien8.de \
--cc=david@kernel.org \
--cc=hsalunke@amd.com \
--cc=kprateek.nayak@amd.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®