On Thu, Jul 09, 2026 at 04:25:27PM +0800, Wandun wrote: > > > On 7/7/26 21:55, Lorenzo Stoakes wrote: > > On Tue, Jul 07, 2026 at 02:44:50PM +0100, Lorenzo Stoakes wrote: > >> See above about deduplicating. > >> > >>> + ttu |= TTU_RESPECT_MLOCK; > >> > >> Hmm. I don't love 'respect mlock'. I guess we only know about the reason > >> being compaction here. > >> > >> But I'm confused anyway. We have the folio, why aren't we just checking for > >> PG_mlocked() here instead of getting the rmap to see if it's mapped > >> anywhere with VMA_LOCKED_BIT? > > > > Also, since compaction_allow_unevictable() is a function that is accessible > > elsewhere, you could literally just have a TTU_MIGRATION here instead and > > have > > the rmap logic call compaction_allow_unevictable() instead rather than this. > Do you mean: > 1. change TTU_RESPECT_MLOCK to TTU_MIGRATION, that'is OK. > 2. move call compaction_allow_unevictable() to try_to_migrate_one? but as you > suggested > migrate_mlock_allowed function, it already called > compaction_allow_unevictable() > in order to determine whether TTU_MIGRATION needs to be added. Did I > misunderstand > something somewhere?
The next paragraph addresses this. > > > > > And then you could adapt the function I suggested before not to take a > > reason > > parameter but rather a 'is_migration' one instead possibly and then pass > > (ttu & > > TTU_MIGRATION) in. > > > > BUT. I still question whether this is at all needed since you have the > > folio you > > can check for PG_mlocked... > > I described a race scenario at this link: > https://lore.kernel.org/lkml/[email protected]/ OK thanks. You really have to spell this out in the code in a comment, this is really non-obvious. I will try to look at your reply in due course (am between jobs atm). > > > > > > Cheers, Lorenzo > Thanks, Lorenzo
