Skip to content

[ROCm][VMM] Combined L1-L4 ROCm VMM allocator (internal integration + validation)#930

Closed
phambinhfin wants to merge 1 commit into
mainfrom
phambinh/vmm-combined-l1-l4
Closed

[ROCm][VMM] Combined L1-L4 ROCm VMM allocator (internal integration + validation)#930
phambinhfin wants to merge 1 commit into
mainfrom
phambinh/vmm-combined-l1-l4

Conversation

@phambinhfin

Copy link
Copy Markdown
Collaborator

Purpose

Internal integration branch that combines all four layered ROCm VMM allocator PRs into a single tree so fork CI can validate the whole stack together. The work is proposed upstream as four separate PRs (links below); this PR is the integration/validation view, not the upstream submission.

Layer Upstream PR Contents
L1 openxla#43942 RocmRawMemoryAllocation (hipMemCreate/Release RAII)
L2 openxla#43943 RocmMemoryReservation + base MemoryReservation::Remap
L3 openxla#43946 RocmVmmAllocator (all-in-one create+reserve+map)
L4 openxla#43947 RocmDeviceAddressVmmAllocator + generic base + factory + tests

Combined diff: +2432 / −17 across 21 files (allocator layers only — no gpu_executable/PJRT enablement, no unrelated churn).

Local validation (AMD MI300X, gfx942)

@xla//xla/stream_executor/rocm:rocm_raw_memory_allocation_test         PASSED
@xla//xla/stream_executor/rocm:rocm_memory_reservation_test            PASSED
@xla//xla/stream_executor/rocm:rocm_vmm_allocator_test                 PASSED
@xla//xla/stream_executor/rocm:rocm_device_address_vmm_allocator_test  PASSED
Executed 4 out of 4 tests: 4 tests pass.

Built from /workspace/rocm-jax/jax with --config=rocm against this working tree.

End-to-end performance (why this stack exists)

These numbers come from the optimization that rides on top of this allocator (the selective copy-vs-remap pass in gpu_executable.cc, #926). They reflect the full VMM stack (this allocator + NEVER_UPDATE + the copy-vs-remap optimization) and are included here to motivate the allocator layers — the allocator alone is the enabler, not the source of the speedup.

MI300X x8, 8 layers / 30 steps, median of steps ≥3; 0 unmap errors.

auto + collective leg (coll_vmm): disabled (=0) vs auto (=1)

Model base (no VMM) disabled (=0) auto (=1) saved speedup (vs disabled) auto vs base
llama2_7b 289.0 ms 133.5 ms 121.0 ms 12.5 ms 9.4% +58.1%
llama3_8b 154.0 ms 168.0 ms 156.5 ms 11.5 ms 6.8% −1.6%
mixtral_8x1b 681.0 ms 690.5 ms 677.5 ms 13.0 ms 1.9% +0.5%
llama3.1-8b 761.0 ms 713.5 ms 704.5 ms 9.0 ms 1.3% +7.4%
gemma2-9b 1528.0 ms 1319.5 ms 1313.0 ms 6.5 ms 0.5% +14.1%

vmm leg (no collectives): disabled (=0) vs auto (=1)

Model base (no VMM) disabled (=0) auto (=1) saved speedup (vs disabled) auto vs base
llama2_7b 289.0 ms 138.5 ms 126.0 ms 12.5 ms 9.0% +56.4%
llama3_8b 154.0 ms 168.5 ms 158.0 ms 10.5 ms 6.2% −2.6%
mixtral_8x1b 681.0 ms 697.0 ms 685.0 ms 12.0 ms 1.7% −0.6%

The per-step saving (~6–13 ms) is roughly fixed (work removed = remap of the small churning slices), a net win that never regresses; auto matches a hand-tuned fixed 4 KB cutoff.

Notes

  • ROCm-only allocator targets; the generic base + factory are vendor-neutral (CUDA + ROCm).
  • Do not merge upstream from here — land the four per-layer PRs instead.

Combined branch bringing together the four layered ROCm VMM allocator PRs for
end-to-end internal validation on AMD hardware:

- Layer 1: RocmRawMemoryAllocation  (openxla#43942)
- Layer 2: RocmMemoryReservation + base MemoryReservation::Remap  (openxla#43943)
- Layer 3: RocmVmmAllocator  (openxla#43946)
- Layer 4: RocmDeviceAddressVmmAllocator + generic base + factory + tests  (openxla#43947)

This is the integration view of the series; the per-layer PRs above are how the
work is proposed upstream. ROCm-only allocator targets; the generic base +
factory are vendor-neutral and used by both CUDA and ROCm.
@phambinhfin phambinhfin closed this Jun 9, 2026
@phambinhfin phambinhfin deleted the phambinh/vmm-combined-l1-l4 branch June 9, 2026 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant