Migration des pages à la demande

With managed memory the data has no fixed home. It quietly moves between CPU and GPU through on-demand page migration, following wherever you use it.

The system tracks memory in fixed chunks called pages, often 4 KB or 64 KB. Migration happens one page at a time, not byte by byte.

When the GPU touches a page that lives on the CPU, it raises a page fault. The driver pauses, copies that page over, then lets the thread continue.

The rule is simple: data migrates to whoever uses it. Write on the CPU and pages live there; read in a kernel and they move to the GPU.

The cost shows up on the first access from a new side. After the page arrives, later reads on that same device are fast and local.

If the CPU and GPU keep touching the same pages in turns, they bounce back and forth. This ping-pong migration can quietly wreck your throughput.

Each fault carries setup overhead, so thousands of tiny faults are costly. Migrating in bulk beats faulting one scattered page after another.

Even with automatic migration, good access patterns win. Threads reading nearby addresses pull in whole pages efficiently instead of scattering faults.

Migration lets you allocate more than the GPU holds. Pages flow in as needed and old ones evict, so huge datasets still run, just slower.

Profilers like Nsight Systems show migration traffic and fault counts. Spotting heavy migration tells you exactly where to add hints next.

On-demand migration is wonderfully automatic, but the faults are not free. Knowing the cost is what lets you fix it with prefetch and advice.

Let us make sure you know what kicks off a migration.

You saw that managed pages migrate on a fault to whoever uses them. First touch is slow, ping-pong hurts, and bulk movement wins. Onward! 🚀