Re: [PATCH RFC v2] mm: introduce copy_mc_highpages() and batch copy in folio_mc_copy()
From: Garg, Shivank
Date: Mon Oct 19 2026 - 16:03:57 EST
On Mon, 2026-10-19 at 16:21 +0200, David Hildenbrand (Arm) wrote:
> On 10/19/26 15:10, Garg, Shivank wrote:
> > On Mon, 2026-10-19 at 14:23 +0200, David Hildenbrand (Arm) wrote:
> > > >
> > > > I would suggest that perhaps this should be the fallback for non-preemptible
> > > > models. But it gets a little weird with PREEMPT_DYNAMIC I think?
> > >
> > > Why can't we just use PROCESS_PAGES_NON_PREEMPT_BATCH where we have similar
> > > handling already?
> > >
> > > >
> >
> > I did not reuse PROCESS_PAGES_NON_PREEMPT_BATCH because it depends on
> > whether clear_pages is defined. While COPY_MC_PAGES_NON_PREEMPT_BATCH
> > depends on copy_mc_to_kernel and other constraints. So, using a single
> > param for both would make it more messy.
>
> If it would stay it would all have to be cleaned up to end up with a single one.
Agreed.
>
> >
> > However as Pedro pointed, most architectures are full preempt/preempt lazy,
> > and with this commit 7dadeaa6e851 ("sched: Further restrict the
> > preemption modes"), for PREEMPT_DYNAMIC, preempt=none and preempt=voluntary
> > are rejected at boot. preempt_model_preemptible() is therefore always
> > true for this case.
> >
> > So, this can be simplfied to drop the COPY_MC_PAGES_NON_PREEMPT_BATCH.
>
> Can we simplify the zeroing part as well?
Yes, I think so that it can be simplified similarly. I'll add a RFC patch
on next version.
Thanks,
Shivank