Re: [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-07-07 15:54:57 [+0100], Lorenzo Stoakes wrote:
> On Tue, Jul 07, 2026 at 08:59:25PM +0800, Wandun Chen wrote:
> > From: Wandun Chen <chenwandun@lixiang.com>
> >
> > The region covered by mlock[all] may contain CMA pages. cma_alloc installs
> > migration entries in the page table, if a memory access occurs at this
> > point, it must wait for the migration to complete, which may cause
> > latency spikes on the RT kernels.
> >
> > Try to move the migration cost into the mlock[all] caller, which is
> > typically a setup path. So reduce the chance of latency spikes on RT
> > kernels by migrating the currently mapped CMA pages out of CMA region.
> 
> 'reduce the chances of latency' so do you have any data to back this invasive
> change or not?

The application gets pages assigned which belong a CMA area. If the
pages are in need by the CMA then those pages are replaced with other
pages during a migration phase. Since there is no guarantee how long
this will take and is also subject to general scheduling in the system
it will be measurable and painful once hit.

> And for RT, but nothing in here at all checks for RT? You're using this
> compaction sysctl as an RT check somehow? That's gross.

The man-page for mlock says that it guarantees to stay in RAM and/ or
preventing to be moved to swap area. I would however argue that
replacing physical pages in the background should fall under this since
the application can't access them and is blocked while trying. The notes
section (in the man-page) lists "real-time applications" and
"deterministic timing".  Therefore I think it makes sense to do this
unconditionally for mlock areas regardless of the sysctl knob.
Security related application probably only care that their memory does
not hit the swap area and probably wouldn't mind 10ms delay.

> This doesn't feel like the right solution.

Sebastian