Day 4 introduced Host-managed Device Memory but deliberately left one question open: how is the coherence of that memory actually managed? Day 5 answers it — and the answer, "bias modes," is the concept that separates a CXL accelerator that performs well from one that crawls. This lesson closes Phase 1's foundations.
The Problem Bias Modes Solve
Consider a Type 2 device — say a GPU with its own local memory that's mapped into the host's coherent address space (Day 4). That memory can be touched by two agents: the host CPU (via CXL.mem) and the device itself (its accelerator cores working locally). Whenever two agents can touch the same memory, coherence has to be maintained — but doing that the naive way, with the device coordinating with the host on every single access to its own memory, would be catastrophically slow. The device would pay a host round-trip just to read the memory sitting right next to it.
Bias modes exist to avoid exactly that. They let a page of device memory declare, in effect, "right now, who's really using me?" — and skip unnecessary coordination accordingly.
The Two Bias States
Each region of a device's memory tracks a bias state that determines whether the device needs to involve the host before accessing it:
🏠
Host BiasThe device must send a request to the host to resolve coherency before touching that device memory. The system checks the host cache for modified copies first; if a modified line exists, it's written back to device memory and the host copy invalidated. Correct, but slower.
⚡
Device BiasThe device may access its own memory independently of the host — no coordination needed. This gives lower latency and higher throughput, and is the mode you want while the accelerator is actively computing on its local data.
How Bias Is Used in Practice
The two modes map cleanly onto the two phases of a typical accelerator workload:
While the accelerator computes on data in its local memory, that memory is put in device bias — the device runs at full speed, untroubled by the host.
When the host needs to read results back (or hand new input in), the relevant memory is switched to host bias, so the host is guaranteed a coherent view.
This is the practical heart of Type 2 performance: a well-written CXL accelerator flips bias per phase of its workload, staying in device bias for the compute-heavy parts and only paying host-coordination cost at the hand-off points. Get this wrong — leaving hot data in host bias during compute — and the accelerator spends its time waiting on host round-trips instead of computing.
The Underlying Coherence Models: HDM-H and HDM-DB
Bias modes are the user-facing behavior; underneath, CXL defines distinct coherence models for host-managed device memory (HDM). Two are central:
Model
Who Manages Coherence
Mechanism
HDM-H (host-managed)
The host is fully responsible; the device does not act for coherency
The simplest model — used by Type 3 memory expanders, which have no cache and don't need to manage coherence themselves
HDM-DB (device-managed, Back-Invalidate)
The device manages coherence of its own local memory
Uses Back-Invalidate Snoop (BISnp) — the device can actively send snoops to invalidate copies held elsewhere, including in the host
Back-Invalidate Snoop (BISnp) — The Device Fights Back
Recall from Day 3 that in the basic model, coherence flows one way: the host snoops devices, never the reverse. HDM-DB changes that. With Back-Invalidate Snoop, the device can itself send snoop requests upstream — to the host and to other agents — to invalidate stale copies of its memory. This is what "device-managed coherence" actually means in mechanism: the device is no longer a passive participant that only answers the host's snoops; it can proactively enforce coherence on its own memory. HDM-DB and BISnp become especially important in the richer multi-host fabrics of CXL 3.0 (Day 8), where the simple host-only model no longer scales.
Tying it together: Type 3 memory expanders use the simple HDM-H model (host does everything). Type 2 accelerators use bias modes to switch between fast device-local access and host-coherent access, and increasingly rely on HDM-DB / BISnp so the device can actively manage the coherence of its own memory. The right combination depends entirely on the device's role — which is exactly the Day 4 lesson, now viewed through the lens of coherence.
🎯 Day 5 Key Takeaways
Type 2 device memory can be touched by both the host and the device — coherence must be maintained without crippling every local access
Bias modes let a region of device memory declare who's really using it: host bias (device coordinates with host first) or device bias (device accesses directly, no host round-trip)
Device bias is the fast path — used while the accelerator computes; host bias guarantees the host a coherent view — used at hand-off points
Flipping bias per workload phase is central to Type 2 accelerator performance; getting it wrong means waiting on host round-trips instead of computing
HDM-H: host fully manages coherence (Type 3 expanders). HDM-DB: device manages its own memory's coherence via Back-Invalidate Snoop (BISnp)
BISnp lets the device proactively snoop upstream — including the host — reversing the host-only snoop model, and matters most in CXL 3.0's multi-host fabrics
Frequently Asked Questions
What are CXL bias modes?
Bias modes govern how coherence is handled for a Type 2 device's own memory. In host bias, the device must coordinate with the host to resolve coherence before accessing its own memory. In device bias, the device can access its own memory directly without involving the host, giving lower latency and higher throughput. A page of device memory tracks which bias state it is in.
What is the difference between host bias and device bias?
In host bias, coherence is ensured by checking the host cache for modified copies of a line before the device accesses that device memory — the device pays a coordination cost. In device bias, the device accesses its own memory independently of the host, which is far faster because it skips the host round-trip. Host bias is used when the host still needs a coherent view; device bias is used when the accelerator is working on the data itself.
What are HDM-H and HDM-DB?
HDM-H (host-managed coherence) means the host is fully responsible for managing the coherence of a device's host-managed device memory; the device does not act for coherency. HDM-DB (device-managed coherence using Back-Invalidate Snoop) means the device manages coherence of its own local memory and can actively send Back-Invalidate Snoop (BISnp) requests to other agents, including the host.
What is Back-Invalidate Snoop (BISnp)?
Back-Invalidate Snoop (BISnp) is a mechanism in HDM-DB mode that lets a device actively send snoop requests to invalidate copies of its memory held elsewhere, including in the host. It's what allows the device — not just the host — to manage the coherence of its own local memory, a capability the simpler host-managed model does not provide.
Why do bias modes matter for accelerator performance?
Bias mode decides whether the accelerator hits a fast or slow path to its own memory. When the accelerator is actively computing on data in its local memory, device bias lets it access that memory at full speed without any host coordination. When the host needs to read results back, switching that memory to host bias ensures the host gets a coherent view. Choosing bias correctly per phase of a workload is key to CXL accelerator performance.