Why does cache write-back happen the way it does?

Question

When a system writes data to cache, it must at some point write that data to the backing store as well.

Why? My course note's don't justify this. Is any component but the processor interested in what's in the cache? Apparently this mirroring isn't even very urgent, as we can postpone the the writes...

The timing of this write is controlled by what is known as the write policy.

There are two basic writing approaches:

...

Write-back (or write-behind): initially, writing is done only to the cache. The write to the backing store is postponed until the cache blocks containing the data are about to be modified/replaced by new content.

So it's postponed until it's about to be replaced? How does that make any sense -- you're mirroring information that you know is about to change! Why not do it when blocks are added?

I'm not sure if I understand your question well, but it seems that you think that replacement mechanism is just modifying the data. When a block is replaced, it means that a completely different memory location now occupies that particular physical space of the cache. It's not only replacing the data. — hayesti
@hayesti I don't understand your comment. Yes, the cache data has changed, and it needs to be synchronized with the cache data in RAM (for a reason I still don't understand). What do you mean by "the data"? — Lynn
Oh wait, I see -- we're not writing back the data about the cache, we're writing back the data that the cache is representing, obviously! This answers both of my questions :) — Lynn
My misconception was that we needed to make a copy in RAM of the entire L1 cache for some reason, but of course, what my notes/Wikipedia are talking about is copying the data in the cache back to its source. — Lynn
(Welp, I've voted to close my own question as off-topic/non-reproducible, because this is just a silly misunderstanding. Feel free to do the same.) — Lynn

gudok gudok · Accepted Answer · 2016-01-15T21:56:49

Let's assume that we are talking about CPU caches. Actually, following rules are true for all types of write-back caches (e.g. databases and the like).

One goal of caches is to make use of temporal locality: small number of memory addresses are written very often to ("hot" addresses), while all other addresses are "cold". Example of "hot" addresses is program's stack because each time your program enters function, arguments are copied onto stack, and each time your program exists function, arguments are removed from it. Thus, the same stack addresses are constantly reused. It would be very slow to work directly with RAM in this case (RAM latency is ~200 CPU cycles and L1 cache latency is only ~4 cycles). That's why when write operation is executed, it modifies only cache entries, and this cache entry is also marked as "dirty". This cache entry will be synchronized with RAM later, when one of following events occurs:

Write operation was performed to some address which is not present in cache. Because all cache entries are normally occupied, we need to search for "victim" cache entry. If this "victim" cache entry is dirty (a), then it needs to be copied into main memory (slow operation, CPU is blocked while it is executed). If not (b), then this cache entry is simply dropped (fast).
Memory subsystem tries to reduce the probability of (a) in favor of (b). It is achieved by periodically copying all dirty cache entries in background and removing dirty flag from them.

Why does cache write-back happen the way it does?

1 Answers