On Thu, Jul 09, 2026 at 04:25:27PM +0800, Wandun wrote:

On 7/7/26 21:55, Lorenzo Stoakes wrote:

quoted

On Tue, Jul 07, 2026 at 02:44:50PM +0100, Lorenzo Stoakes wrote:

quoted

See above about deduplicating.

quoted

+			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.

quoted

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.

quoted

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/c372e68f-2bfc-45b6-a431-01bf55717247@gmail.com/ (local)

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).

quoted

Cheers, Lorenzo

Thanks, Lorenzo