"Write back" writes data to the cache, and does not update memory until the cache line is evicted. "Write-through" always writes data to cache and memory. The former has smaller latency (in non-parallel programs) but has implications for multiple caches (since data in memory might be stale).
"Write allocate", on a write miss, will load the cache line and write to the cache. "Write-no-allocate" will write the block immediately to memory.
doodooloo
So do we only talk about "write back vs. write-through" in the context of a write miss?> and only talk about "write allocate vs. write-no-allocate" in the context of a write hit?>?
amaliujia
@doodooloo Cite from wiki:
"Both write-through and write-back policies can use either of these write-miss policies, but usually they are paired in this way:
A write-back cache uses write allocate, hoping for subsequent writes (or even reads) to the same location, which is now cached.
A write-through cache uses no-write allocate. Here, subsequent writes have no advantage, since they still need to be written directly to the backing store."
kamladi
@doodooloo In other words, "write-back" and "write-through" are write-hit policies, whereas "write-allocate" and "write-no-allocate" are write-miss policies. Therefore, a write-hit policy is paired with a write-miss policy (as described by @amaliujia) to create an overall write policy.
jazzbass
@regi a small clarification on your recap: If a cache is write-through, it does not mean that it will always propagate it's writes all the way up to main memory, it only means that it will propagate its writes to the memory storage immediately above it in the memory hierarchy. For example, if a L1 cache is write-through (unusual, but possible), it only means that on every write to L1, it will also propagate the write to the L2 cache, but not to main memory. If L2 is a write-back cache, L1's write won't reach main memory until the cache line in L2 is evicted.
apoms
I was confused as to why one would want a write-back write-hit policy with a write-no-allocate write-miss policy because that seemed liked it would defeat the purpose of the write-back buffering. However, there is a case where you still get the benefit of a write-back: when you have performed a read to some cache line, any subsequent writes to that line will be buffered until the line is evicted. Write-no-allocate only applies when the cache line you are writing to is not in the cache yet. In fact, if you had a write-no-allocate cache and were planning on writing to several locations in a line, it would make sense to first read some location in that line to bring it into the cache and then perform your writes on the line. This way the writes would be buffered and you would avoid multiple direct writes to memory and the associated latency costs.
Cache Write Policy and Performance: http://www.researchgate.net/profile/Norman_Jouppi/publication/220771910_Cache_Write_Policies_and_Performance/links/00b495294016502808000000.pdf
To recap:
"Write back" writes data to the cache, and does not update memory until the cache line is evicted. "Write-through" always writes data to cache and memory. The former has smaller latency (in non-parallel programs) but has implications for multiple caches (since data in memory might be stale).
"Write allocate", on a write miss, will load the cache line and write to the cache. "Write-no-allocate" will write the block immediately to memory.
So do we only talk about "write back vs. write-through" in the context of a write miss?> and only talk about "write allocate vs. write-no-allocate" in the context of a write hit?>?
@doodooloo Cite from wiki: "Both write-through and write-back policies can use either of these write-miss policies, but usually they are paired in this way: A write-back cache uses write allocate, hoping for subsequent writes (or even reads) to the same location, which is now cached. A write-through cache uses no-write allocate. Here, subsequent writes have no advantage, since they still need to be written directly to the backing store."
@doodooloo In other words, "write-back" and "write-through" are write-hit policies, whereas "write-allocate" and "write-no-allocate" are write-miss policies. Therefore, a write-hit policy is paired with a write-miss policy (as described by @amaliujia) to create an overall write policy.
@regi a small clarification on your recap: If a cache is write-through, it does not mean that it will always propagate it's writes all the way up to main memory, it only means that it will propagate its writes to the memory storage immediately above it in the memory hierarchy. For example, if a L1 cache is write-through (unusual, but possible), it only means that on every write to L1, it will also propagate the write to the L2 cache, but not to main memory. If L2 is a write-back cache, L1's write won't reach main memory until the cache line in L2 is evicted.
I was confused as to why one would want a write-back write-hit policy with a write-no-allocate write-miss policy because that seemed liked it would defeat the purpose of the write-back buffering. However, there is a case where you still get the benefit of a write-back: when you have performed a read to some cache line, any subsequent writes to that line will be buffered until the line is evicted. Write-no-allocate only applies when the cache line you are writing to is not in the cache yet. In fact, if you had a write-no-allocate cache and were planning on writing to several locations in a line, it would make sense to first read some location in that line to bring it into the cache and then perform your writes on the line. This way the writes would be buffered and you would avoid multiple direct writes to memory and the associated latency costs.