Re: [PATCH RFC v2] mm: introduce copy_mc_highpages() and batch copy in folio_mc_copy()

["Garg, Shivank" <shivankg@amd.com>]

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