On Thu, 7 Aug 2025, Vlastimil Babka wrote: > On 8/1/25 15:40, Alexander Krabler wrote: > > On 8/1/25 14:57, Vlastimil Babka wrote: > >> Hm that means something isn't working as intended. Do the pages have also > >> the unevictable flag? > > > > I have checked /proc/<pid>/smaps. > > Neither the manpage > (https://www.man7.org/linux/man-pages/man5/proc_pid_smaps.5.html) > > nor kernel source code (fs/proc/task_mmu.c show_smap_vma_flags) tells me > about unevictable flag. > Ah ok, you checked /proc/pid/smaps. Since you said "pages" I thought you > meant individual pages which would be from /proc/kpageflags > > But IIRC getting a page in a state where it has an mlock flag but (not yet) > the unevictable flag should be rare so I would be surprised if that was the > problem here. Agreed. > > Hm or maybe it's actually that the error can happen only in the other > direction - page is unevictable (on unevictable list) while not mlocked, at > least the counters such as UNEVICTABLE_PGRESCUED suggest that. > > Hugh knows this code the best. Do you think we should e.g. test the mlocked > flag instead/in addition to unevictable flag in compaction to avoid > violating vm.compact_unevictable_allowed = 0? No, checking for unevictable should be sufficient. But another idea has just this moment occurred to me: anon THP splitting is another user of migration entries. Is it possible that kcompactd is not actually the cause of Alexander's issue, but that his RT tasks have (bad news! shouldn't be allowed) got anon THPs in them? Back to bed, Hugh
