Just to check if I understand the distinctions between write buffer and write-back buffer. Write buffer is used to buffer processors' requests to write. All writes in write buffer are not indeed written so that it is not visible to other processors. The goal of write buffer is to hide write latency to allow reads to be performed immediately. By contrast, contents in write-back buffer are cache lines that should be flushed to memory immediately otherwise, which should be visible to other processors. The goal is to let processors continue immediately without blocking by the write operation.
rbandlam
In class, we had discussion that adding write-back buffer is like increasing cache size or not. What advantages will write-back buffer bring over simply increasing cache size?
I feel like adding write-back buffer helps in reducing number of memory accesses when there are lot of conflict misses on some particular cache line. For example, when one processor is accessing memory addresses such that they fall in same cache line: without write-back buffer on every conflict there has to be memory write but when another processor accesses same address, it has to be fetched from memory but with write-back buffer ownership of that address changes from one processor to another processor without involving memory access. I feel this is one advantage with write-back buffer.
mingf
The most obvious distinction between write buffer and write-back buffer is that stuff in write buffer are not actually committed whereas stuff in write-back buffer have already taken place and thus should be seen by other processors. Both buffers have similar goal, which is to hide latency. Oftentimes we have more things to do instead of waiting write operations to complete.
kayvonf
The key work here is "committed". A write commits when it is observed by all processors. It's more precise to say committed than completed, since a committed write may in fact not be "completed" yet. "Completed" might mean something like: the bits in the cache are updated and cache has nothing else to do to related to the write. A write can certainly commit before the bits are tucked away in the cache's SRAM.
As @mingf nicely said. All writes in the write-back buffer certainly committed a long time ago. Potentially hours, if the line was maintained in cache that long. ;-)
cgjdemo
What will happen when a dirty line is in write-back buffer when another processor requests this line? Will this trigger the write-back buffer to flush its content immediately to memory?
It seems that the processor still needs to wait for a flush before continue. So is it expected that in most case, a flush triggered by other processors' request could happen before a new write-back happens?
landuo
Just to check my understanding of the difference between write buffer and write-back buffer. Write buffer of a processor hides latency because it allows processor to continue while a write request is pending.Every line in the write buffer are write requests that processor generated but not yet committed (seen by other processors). On the other hand, lines in write-back buffer are already observed by other processors. Because we would like the processor to continue as soon as possible and the time when lines in write-back buffer are actually written into memory does not has significant impact, a write-back buffer can also help to hide latency.
I have a question here. Is it valid to say that lines in write-back buffer comes from the write buffer?
Elias
I have a question about allocation: how do you decide how large your write back/write buffers should be? Presumably, you can't build the system before you choose. Is this another case of "model it in software?"
kayvonf
Correct. Hardware companies and computer architecture researchers use detailed chip simulations to evaluate designs prior to investing billions of dollars to build a chip.
mangocourage
In lecture Kayvon asked a question on this slide regarding consistency. Can anybody restate the question/answer?
byeongcp
@mangocourage I think the question was something along the line of "why doesn't the solution (using write-back buffer) listed in this slide not violate the memory consistency?"
I'm not 100% sure about this, but I think it doesn't violate the memory consistency since snooping busRdX (for other processors) now requires the extra step of checking the write-back buffer to observe the write from the processor that had the exclusive write.
HLAHat
The other thing is that all values in the write-back buffer have already had their writes committed. This means all processors have seen the write even if the write hasn't fully "completed." Memory consistency has to do with the order in which processors see reads and writes. Since things in the write-back buffer are committed those write events have been placed on the memory consistency "timeline" anything that happens afterwards with those lines doesn't really affect consistency.
marjorie
I'm still a bit confused about why it's useful to distinguish between a write committing and completing. Why is it useful to say that the write has committed if it still hasn't actually happened? It seems to me that if the computer crashed after the write had committed but before it actually wrote to memory, that data would be lost. So it's "committed," but it's not inevitable that it will complete, correct?
Do we focus on the moment of commitment because we're assured that, after that moment, the other caches will Is it because, even if the write hasn't completed, the other caches will still find it when they try to load that data?
Elias
@marjorie: I think you've got the idea. We're concerned with the concept of a write being committed only for cache coherence. It's important to understand when the write is "finished" as observed by other caches, but this doesn't mean the data is persisted. Data in SRAM can be (and is) lost if something dramatic (like a power outage) occurs, and this does present a problem for some systems.
Kapteyn
What happens if a cache wants to write to a line in its own write-back buffer? Will a typical cache check its own write-back buffer first and reload the line from there instead of issuing a BusRdx?
Just to check if I understand the distinctions between write buffer and write-back buffer. Write buffer is used to buffer processors' requests to write. All writes in write buffer are not indeed written so that it is not visible to other processors. The goal of write buffer is to hide write latency to allow reads to be performed immediately. By contrast, contents in write-back buffer are cache lines that should be flushed to memory immediately otherwise, which should be visible to other processors. The goal is to let processors continue immediately without blocking by the write operation.
In class, we had discussion that adding write-back buffer is like increasing cache size or not. What advantages will write-back buffer bring over simply increasing cache size?
I feel like adding write-back buffer helps in reducing number of memory accesses when there are lot of conflict misses on some particular cache line. For example, when one processor is accessing memory addresses such that they fall in same cache line: without write-back buffer on every conflict there has to be memory write but when another processor accesses same address, it has to be fetched from memory but with write-back buffer ownership of that address changes from one processor to another processor without involving memory access. I feel this is one advantage with write-back buffer.
The most obvious distinction between write buffer and write-back buffer is that stuff in write buffer are not actually committed whereas stuff in write-back buffer have already taken place and thus should be seen by other processors. Both buffers have similar goal, which is to hide latency. Oftentimes we have more things to do instead of waiting write operations to complete.
The key work here is "committed". A write commits when it is observed by all processors. It's more precise to say committed than completed, since a committed write may in fact not be "completed" yet. "Completed" might mean something like: the bits in the cache are updated and cache has nothing else to do to related to the write. A write can certainly commit before the bits are tucked away in the cache's SRAM.
As @mingf nicely said. All writes in the write-back buffer certainly committed a long time ago. Potentially hours, if the line was maintained in cache that long. ;-)
What will happen when a dirty line is in write-back buffer when another processor requests this line? Will this trigger the write-back buffer to flush its content immediately to memory?
@cgjdemo. Yes. See the next slide.
What if the write-back buffer is full?
It seems that the processor still needs to wait for a flush before continue. So is it expected that in most case, a flush triggered by other processors' request could happen before a new write-back happens?
Just to check my understanding of the difference between write buffer and write-back buffer. Write buffer of a processor hides latency because it allows processor to continue while a write request is pending.Every line in the write buffer are write requests that processor generated but not yet committed (seen by other processors). On the other hand, lines in write-back buffer are already observed by other processors. Because we would like the processor to continue as soon as possible and the time when lines in write-back buffer are actually written into memory does not has significant impact, a write-back buffer can also help to hide latency.
I have a question here. Is it valid to say that lines in write-back buffer comes from the write buffer?
I have a question about allocation: how do you decide how large your write back/write buffers should be? Presumably, you can't build the system before you choose. Is this another case of "model it in software?"
Correct. Hardware companies and computer architecture researchers use detailed chip simulations to evaluate designs prior to investing billions of dollars to build a chip.
In lecture Kayvon asked a question on this slide regarding consistency. Can anybody restate the question/answer?
@mangocourage I think the question was something along the line of "why doesn't the solution (using write-back buffer) listed in this slide not violate the memory consistency?"
I'm not 100% sure about this, but I think it doesn't violate the memory consistency since snooping busRdX (for other processors) now requires the extra step of checking the write-back buffer to observe the write from the processor that had the exclusive write.
The other thing is that all values in the write-back buffer have already had their writes committed. This means all processors have seen the write even if the write hasn't fully "completed." Memory consistency has to do with the order in which processors see reads and writes. Since things in the write-back buffer are committed those write events have been placed on the memory consistency "timeline" anything that happens afterwards with those lines doesn't really affect consistency.
I'm still a bit confused about why it's useful to distinguish between a write committing and completing. Why is it useful to say that the write has committed if it still hasn't actually happened? It seems to me that if the computer crashed after the write had committed but before it actually wrote to memory, that data would be lost. So it's "committed," but it's not inevitable that it will complete, correct?
Do we focus on the moment of commitment because we're assured that, after that moment, the other caches will Is it because, even if the write hasn't completed, the other caches will still find it when they try to load that data?
@marjorie: I think you've got the idea. We're concerned with the concept of a write being committed only for cache coherence. It's important to understand when the write is "finished" as observed by other caches, but this doesn't mean the data is persisted. Data in SRAM can be (and is) lost if something dramatic (like a power outage) occurs, and this does present a problem for some systems.
What happens if a cache wants to write to a line in its own write-back buffer? Will a typical cache check its own write-back buffer first and reload the line from there instead of issuing a BusRdx?