2026-08-28
When you write to a cache line that isn't in your L1, the CPU has to first read the entire line from memory — a full 64-byte fetch — just so it can modify some bytes and eventually write it back. This is the write-allocate policy at work, and it's usually correct. But when you're about to overwrite the whole line anyway (think memset(buf, 0, size) or the first touch of a freshly allocated page), that read is pure waste: bytes travel from DRAM to cache only to be immediately clobbered.
Cache line zeroing instructions solve this. AMD's CLZERO and ARM's DC ZVA (Data Cache Zero by Virtual Address) tell the CPU: "allocate this line in cache, set all bytes to zero, and do not fetch anything from memory." The CPU claims the line in Exclusive/Modified state via the coherence protocol, fills it with zeros from a hardwired source, and the line is dirty in your L1 without ever touching DRAM.
Concrete example: ARM's memset in glibc uses DC ZVA for large zero fills. On a Cortex-A72 with a 64-byte cache line, zeroing 4 KB the naive way costs 64 read-for-ownership fetches (4096 bytes of pointless DRAM traffic). With DC ZVA, it costs zero read traffic — just 64 coherence transactions to claim lines. Measured speedup on cold buffers: 2-4x faster, and it frees up memory bandwidth for other cores.
The catches:
DCZID_EL0 register. Hardcoding 64 is a portability bug.Rule of thumb: If you're about to write more than half a cache line and don't need the old contents, a zeroing instruction (or non-temporal store) saves you one DRAM fetch per 64 bytes. On a system with 25 GB/s of memory bandwidth, that's up to 390 million lines/second of savings — a full DRAM channel's worth of pointless traffic reclaimed.
Intel notably lacks a general-purpose CLZERO equivalent for userspace (only for AMD chips), so portable code often falls back to REP STOSB, which modern Intel CPUs internally optimize with a similar allocate-zero fast path in the microcode.
