Ember keeps oversized GPU workloads moving with adaptive placement
In parole semplici
GPU memory is fast but limited. When a program needs more data than fits, its usual manager may keep moving pages and stall the work; leaving data in host memory avoids those moves but makes every access cross a slower link.
Ember is a framework that starts data in host memory and can move frequently used regions to the GPU. In tests of six data-intensive applications, both Ember versions had faster mean runtimes than default UVM on each of three GPUs when the data exceeded GPU memory.
La ricerca
When a GPU workload exceeds its memory, moving pages can stall computation, while leaving all data in host memory makes each access cross a slower link. Can placement change as a program's data needs change, without leaving the GPU's memory full of regions it no longer uses?
Ember offers fixed and adaptive placement: both map data in host memory by default, while the adaptive version uses GPU access counts to promote active regions and reclaim colder ones before memory fills.
On six data-intensive applications at about 1.5 times GPU-memory capacity, the authors compared both Ember versions with default UVM. They measured application runtime and reported mean speedups separately for each version and GPU; both versions had faster means on all three tested GPUs.
Because each mean summarizes six applications, the result supports faster average runtimes across that test set, not an equal gain for every application.
These results cover the tested GPUs, workloads and memory conditions; average speedups do not mean every application improved. Ember manages only cudaMallocManaged allocations, and its adaptive version infers when GPU-resident regions have cooled from their earlier access demand.