On 8/1/25 04:46, Mike Galbraith wrote: > On Thu, 2025-07-31 at 20:41 +0200, Vlastimil Babka wrote: >> On 7/31/25 20:34, Frank van der Linden wrote: >> > Not sure what the right thing to do would be. Either explicitly boost >> > the priority of a thread temporarily during migrate_pages_batch, or >> > mitigate the issue by dealing with 'busy' pages more quickly in >> > migrate_pages_batch. >> >> There's a workaround for realtime tasks. If you mlock[all]() their memory, >> setting sysctl vm.compact_unevictable_allowed to 0 should exclude these >> pages from migration by compaction. > > Hm, per documentation that's done automatically for PREEMPT_RT... Oh I see. > On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due > to compaction, which would block the task from becoming active until the fault > is resolved. So it's probably the mlock() part missing since that should otherwise apply to kcompactd. > ...but rummaging, seems other stuff can step on it (contiguous alloc?). Yeah, there was time CMA was just something for mobile phone hardware. As usage increases beyond that maybe we'll have to tackle it. Ideally by not having mlock'd pages in CMA areas at all. And if contiguous alloc is attempted outside of CMA areas, respect the sysctl there too. There are also things like mbind() migrating pages for NUMA locality but I assume people just wouldn't try to do that with realtime workloads. > -Mike
