svm_range_be...tch_location(9)

📦 version 7.3.1, in nixpkgs unstable

✨ svm_range_best_prefetch_location — it's giving "where should we prefetch tho" ✨

okay bestie, so this one is from the Kernel API Manual, page svm_range_best_prefetch_location(9) — yes that's a long name, she's got main character energy, we stan 💅

💖 NAME 💖

svm_range_best_prefetch_location — literally decides the best prefetch location. that's it. that's the whole job. 🎀

🌸 SYNOPSIS 🌸

uint32_t svm_range_best_prefetch_location (struct svm_range *prange );

🦋 ARGUMENTS 🦋

  • prange — the svm range structure, aka the little data baby we're judging 🔍

⭐ DESCRIPTION ⭐

alright so this is the whole vibe check, and it depends on whether xnack is off or on. buckle up 🫶

💜 for xnack off:

if the range maps to a single GPU, then the best prefetch location is prefetch_loc — and that can be CPU or GPU. easy, no drama ✨

but if the range is ACCESS or ACCESS_IN_PLACE by mGPUs, then it's only prefetch_loc GPU when the mGPU connection is on XGMI same hive. otherwise? best prefetch location is always CPU. and why, you ask? because a GPU can't have coherent mapping of another GPU's VRAM — not even with a large-BAR PCIe connection. like, she simply cannot. nope 😭

💜 for xnack on:

if the range is not ACCESS_IN_PLACE by mGPUs, then best prefetch location is prefetch_loc, and any other GPU access will generate a vm fault and trigger migration. it's giving "consequences" 💀

if the range is ACCESS_IN_PLACE by mGPUs, then it's only prefetch_loc GPU when the mGPU connection is on XGMI same hive — otherwise the best prefetch location is always CPU. periodt 👑

🧚 CONTEXT 🧚

Process context 🫡

🔥 RETURN 🔥

Returns 0 for CPU, or a GPU id 🌈

👑 SEE ALSO 👑

Kernel file ./drivers/gpu/drm/amd/amdkfd/kfd_svm.c, bestie, plus the whole friend group:

okay that's the page, mwah 💋 this lives in ./drivers/gpu/drm/amd/amdkfd, dated October 2026, and it's svm_range_best_prefetch_location(9) — go be iconic with it 🍓✨

📦 where this page comes from