* [PATCH RFC] mm/memory: drop PROCESS_PAGES_NON_PREEMPT_BATCH
@ 2026-10-22 8:14 Shivank Garg
2026-10-22 9:58 ` Pedro Falcato
0 siblings, 1 reply; 2+ messages in thread
From: Shivank Garg @ 2026-10-22 8:14 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ankur Arora, Pedro Falcato,
Peter Zijlstra, Borislav Petkov, Bharata B Rao,
Hrushikesh Salunke, K Prateek Nayak
Cc: x86, linux-mm, linux-kernel, Shivank Garg
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>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH RFC] mm/memory: drop PROCESS_PAGES_NON_PREEMPT_BATCH
2026-10-22 8:14 [PATCH RFC] mm/memory: drop PROCESS_PAGES_NON_PREEMPT_BATCH Shivank Garg
@ 2026-10-22 9:58 ` Pedro Falcato
0 siblings, 0 replies; 2+ messages in thread
From: Pedro Falcato @ 2026-10-22 9:58 UTC (permalink / raw)
To: Shivank Garg
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ankur Arora, Peter Zijlstra,
Borislav Petkov, Bharata B Rao, Hrushikesh Salunke,
K Prateek Nayak, x86, linux-mm, linux-kernel
On Thu, Oct 22, 2026 at 08:14:30AM +0000, Shivank Garg wrote:
> 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(-)
Awesome!
>
> 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.
Why can't clear_pages() itself do cond_resched()? Same question for
clear_user_pages() and/or clear_user_highpages().
--
Pedro
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-22 9:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-22 8:14 [PATCH RFC] mm/memory: drop PROCESS_PAGES_NON_PREEMPT_BATCH Shivank Garg
2026-10-22 9:58 ` Pedro Falcato
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®