When you write to memory, the store lands in the cache — not DRAM, not persistent memory, not the NIC's coherent buffer. If you need that write to actually escape the cache hierarchy, you need a flush. x86 gives you three instructions, and they are wildly different in cost and semantics.

CLFLUSH (1998, SSE2): The original. Evicts the target cache line from every level of the hierarchy on every core. It's strongly ordered — CLFLUSH serializes with all loads and stores to any address. In practice this behaves almost like an implicit fence: your out-of-order engine drains, then the flush proceeds. Cost: roughly 100-500 cycles per line, plus the pipeline stall.

CLFLUSHOPT (2016, Skylake): Same eviction behavior, but weakly ordered. CLFLUSHOPTs to different cache lines can pipeline. You still need an SFENCE at the end to guarantee ordering with subsequent stores, but flushing 64 lines no longer means 64 sequential 300-cycle stalls. Throughput improvement of 5-10x when flushing ranges.

CLWB (2016, Skylake-SP): Cache Line Write Back. Writes the dirty line to memory but keeps it in cache in the Exclusive state. This is the killer feature for persistent memory (Optane) and any workload that flushes-then-re-reads. Also weakly ordered, also needs SFENCE.

Concrete example — persistent memory log append:

• Write 4 KB (64 cache lines) into a PMEM-backed buffer.
• CLFLUSH loop: 64 × ~300 cycles + serialization = ~20,000 cycles. Line is gone; re-reading it costs a full memory access.
• CLFLUSHOPT loop + SFENCE: ~64 × 30 cycles pipelined + ~50 cycle fence = ~2,000 cycles. Line still gone.
• CLWB loop + SFENCE: same ~2,000 cycles, but the next read of that buffer hits in L1. If you'll touch it again (checkpoint metadata, replaying a log tail), this is free vs. a cold miss.

Rule of thumb: Never write a CLFLUSH loop in new code. If you don't need the line again, use CLFLUSHOPT + SFENCE. If you might, use CLWB + SFENCE. The SFENCE is what makes the flush observable to subsequent stores — the flush instruction alone only guarantees the writeback started, not that it's globally visible.

The gotcha: CLWB on pre-Ice Lake parts was implemented as CLFLUSHOPT internally — the line got evicted anyway. Only from Ice Lake (2019) onward does CLWB actually preserve the cache state. Check CPUID before assuming you're getting the fast path.