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 <[email protected]> > > > > 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
