HMM migrate-on-fault series aims to cut page-table walks
A fourteenth revision unifies fault handling with device-page migration, but automated review flagged livelocks, notifier imbalances, and missing TLB flushes.
Mika Penttilä of Red Hat has posted a fourteenth revision of a memory-management series that lets the kernel fault in missing pages and set up device migration in a single page-table walk, rather than two or three separate passes.
Drivers that move anonymous memory to GPU or other device-private memory today either always fault first and then migrate, paying for an extra walk even when pages are already present, or migrate first and only then fault and migrate again when holes appear. Each walk can cost more than a thousand cycles on x86-64. The series adds request flags so Heterogeneous Memory Management (HMM) range faulting can prepare migration entries as it goes, and so migrate_vma setup can fault missing pages with the desired access rights in the same pass. Documentation and an HMM selftest case cover the new path. Throughput numbers from the existing migrate tests stay within noise of an unmodified kernel.
Automated review of the revision raised multiple high-severity and critical concerns in the new split and migration plumbing: possible livelocks when concurrent threads inflate folio reference counts before locking, unbalanced MMU notifier invalidations on interrupt or NULL owner paths, a missing TLB flush after partial unmap on error, wrong subpage handling for folios larger than 2MB, and a use-after-free window in the test driver’s migrate-on-fault path. A Kconfig change that forces HMM mirror support under device migration drew a lower-severity dependency warning and an ack from Balbir Singh.
Andrew Morton called the motivation sensible but noted that the cover letter still shows no measured performance win beyond parity with the status quo. The work remains under review on the relevant lists.