mm/rmap: Should vma_migratable be checked in try_to_migrate_one?

[Riwan <coefficriwan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

Hi, I’m a phd student working on memory management and I have the following question:
Is it intentional to not check for `vma_migratable` in `try_to_migrate_one` ?
If the vma is not migratable, it would be logical to cancel the page migration at this point.

From what I understand, `vma_migratable` is called to check if a pages in a specific VMA can be migrated or not.
From what I can see, user-facing migration paths (mbind, move_pages) and NUMA balancing already check wether migration is possible or not with `vma_migratable`, but other migration path, such as compaction with kcompactd, ignore this check.
As `try_to_migrate_one` is the only place where we have access to the vma (due to reverse mapping), it would be logical to check here for `vma_migratable` (before we only have access to the folio).

I’m still new to the Linux Kernel, and may have missed critical subsystem / behavior, and I would be curious to know if this was overlooked or if there is a reason behind not calling `vma_migratable`.

From what I could get, here is the relevant context:
- Implem of vma_migratable : mm/mempolicy: check hugepage migration is supported by arch in vma_migratable() (https://lore.kernel.org/all/20200402041052.Y4zsoYman%25akpm@linux-foundation.org/)
- Implem of try_to_migrate_one, previously managed in try_to_unmap_one : mm/rmap: split migration into its own function (https://lore.kernel.org/all/20210701015416.0t4MkxtDR%25akpm@linux-foundation.org/)

Thanks a lot

Riwan Coëffic

[-- Attachment #2: Type: text/html, Size: 2004 bytes --]