On 7/31/25 20:35, 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. > > - Frank I think it would help if priority inheritance would kick in as soon as another thread is waiting due to the migration PTE. On 8/1/25 11:58, Vlastimil Babka wrote: > 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. Yes, vm.compact_unevictable_allowed is set to 0 in our setup (default as we have CONFIG_PREEMPT_RT). > > 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. We use mlockall() and I verified the pages have the lo flag set. Which means, that we have exactly the issue this sysctl flag should prevent us from. > > > ...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. Yeah, we already thought CMA might somehow influcence our issue. We have 256 MiB of CMA, which our hardware probably uses. Is there a way to tell a process to not allocate pages inside CMA area? > > > > -Mike > Alexander KUKA Deutschland GmbH Board of Directors: Michael Jürgens (Chairman), Dirk Busch, Johan Naten, Hui Zhang Registered Office: Augsburg HRB 14914 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly forbidden. Please consider the environment before printing this e-mail.
