On 23/06/2023 15:34, Tudor Cretu wrote:
Speaking of migration, I wonder if we shouldn't do something about aio_migrate_folio(), since it seems to replace the backing pages (I don't completely understand what it does though).
I don't think we need to do anything. IIUC, the migration of the physical location of the pages doesn't change their virtual addresses. From mm/Kconfig:
config MIGRATION bool "Page migration" def_bool y depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU help Allows the migration of the physical location of pages of processes while the virtual addresses are not changed. This is useful in two situations. The first is on NUMA systems to put pages nearer to the processors accessing. The second is when allocating huge pages as migration can relocate pages to satisfy a huge page allocation instead of reclaiming.
So, the vmap should still be valid even after migration.
Right, the vmap mapping does not need to move for sure. However, I am not sure what happens if folio_migrate_mapping() is passed pages that are already mapped by vmap(). Would it magically update the mapping (and invalidate TLBs), or would it fail? For that matter I don't really understand what happens to the userspace mapping either, as clearly userspace doesn't do anything itself. That might require further investigation.
Kevin