I understand that the write back buffer is a good solution for allowing the processor to continue work, and that the snooping mechanism will also have to scan the write-back buffer tags for working correctly. However, is a write-back buffer typically of size only 1 cache line? What dictates the size of the write-back buffer? Is it the cache policy (LRU v/s something else)?
rmanne
I think that the write-back buffer is determined by the hardware. It seems like it's a separate hardware-level buffer which is dedicated to just writing from it's cache level. I don't think the cache policy affects it, unless it was a software implementation.
So I think the size is also determined by this hardware.
huehue
So does the modified line stay in the cache of the processor that modified it until the line needs to be evicted, at which time it goes to the write-back buffer rather than updating memory right away?
stl
When a line gets modified, it stays in the cache until eviction. On eviction the line gets placed in the write-back buffer, which is a queue of dirty lines. The write-back buffer can hide the expensive cost of eviction since now the processor doesn't need to wait for the write to memory to complete. What happens if a line is evicted and placed in the write-back buffer, but then another write to that line happens before it gets flushed to memory? Will the stale line be removed from the write-back buffer?
ArbitorOfTheFountain
I think any access to the line in the write-back buffer from a processor other than the original writer must get the most up-to-date version of the written back line (which means waiting for the buffer to flush up to the relevant line, or prioritizing that line). If two versions of a cache line are flushed from the same processor, the second line can simply be placed in the buffer and both versions must be written back before any other processor accesses them.
I understand that the write back buffer is a good solution for allowing the processor to continue work, and that the snooping mechanism will also have to scan the write-back buffer tags for working correctly. However, is a write-back buffer typically of size only 1 cache line? What dictates the size of the write-back buffer? Is it the cache policy (LRU v/s something else)?
I think that the write-back buffer is determined by the hardware. It seems like it's a separate hardware-level buffer which is dedicated to just writing from it's cache level. I don't think the cache policy affects it, unless it was a software implementation.
So I think the size is also determined by this hardware.
So does the modified line stay in the cache of the processor that modified it until the line needs to be evicted, at which time it goes to the write-back buffer rather than updating memory right away?
When a line gets modified, it stays in the cache until eviction. On eviction the line gets placed in the write-back buffer, which is a queue of dirty lines. The write-back buffer can hide the expensive cost of eviction since now the processor doesn't need to wait for the write to memory to complete. What happens if a line is evicted and placed in the write-back buffer, but then another write to that line happens before it gets flushed to memory? Will the stale line be removed from the write-back buffer?
I think any access to the line in the write-back buffer from a processor other than the original writer must get the most up-to-date version of the written back line (which means waiting for the buffer to flush up to the relevant line, or prioritizing that line). If two versions of a cache line are flushed from the same processor, the second line can simply be placed in the buffer and both versions must be written back before any other processor accesses them.