Since memory is also listening on the bus, does that mean that if there's a write-back buffer match we don't actually have to actively flush? Can we just depend on memory to pick up the data we send from the write-back buffer?
IntergalacticPeanutMaker
The bus access request for the write back is cancelled when the write back buffer is snooped because memory in the buffer is transferred to a new cache during this time.
eknight7
@IntergalacticPeanutMaker : Won't the transfer of the cache line in the write-back buffer only happen when another cache requires it for read/write? Otherwise, the buffer won't be flushed while snooping right? It will probably be flushed at some other time (I don't know when) ?
ZhuansunXt
I don't quite understand the meaning of "Cancel outstanding bus access request(for the write back)". My understanding of this slide is, write back buffer is treated equally as cache on that processor. And the state of cache lines in write back buffer is guaranteed to be "Modified", so if Rd/RdX is received from bus, it will be flushed to memory. Please correct me if I'm wrong, and hope some one could explain on my confusion.
TanXiaoFengSheng
@ZhuansunXt, my understanding is that the snoop controller would simply send the data in write back buffer to the requestor and memory would not respond to this request any more. From slide #33, the setting here seems to be that if some cache has a copy of requested data, that cache should service the request instead of memory. Isn't it different from what's said previously, where the dirty cache data should be flushed to memory first and then memory would service the actual request?
kayvonf
@zhuansunXt. That comment is referring to the fact that if the line is sitting in the write back buffer, presumably the cache has a pending request to acquire to bus to perform the write back (it's waiting in line for access to the bus). However, if the cache has to flush the line as a result of responding to coherence requests, then there's no further reason to flush the line in the write-buffer buffer -- it's already been flushed!
ZhuansunXt
@TanXiaoFengSheng, what you said makes sense, so the "cancel" here means that the cache line in write-back buffer will serve the requester first, canceling transaction of flushing the data to memory temporarily, right? By the way good username :)
ZhuansunXt
@kayvonf, So can I understand it in this way: the main motivation for having write-back buffer is to keep processor as busy as possible to improve throughput. And having this write-back buffer actually havs a nice side-effect: it's able to serve a requestor with modified cache data, which saves the requestor's effort to read the data from memory (and this somehow increases the cache's 'capacity', since a cache line that is supposed to be flushed can be read from a cache now).
kayvonf
@zhuansunXt: I wouldn't say this is an added benefit.
If a line X is in the write back buffer of cache C0, from the perspective of coherence it's another copy of the data (despite it technically not being in the case). If another cache C1 needs the line X, then the write-back buffer needs to get flushed so the requestor receives the most up-to-date data.
In a basic implementation X could be flushed to memory, and then C1 reads the up-to-date data from memory. In a more advanced implementation X could be transferred over to C1.
In either case, the presence of the write-buffer buffer does not provide new system functionality.
Since memory is also listening on the bus, does that mean that if there's a write-back buffer match we don't actually have to actively flush? Can we just depend on memory to pick up the data we send from the write-back buffer?
The bus access request for the write back is cancelled when the write back buffer is snooped because memory in the buffer is transferred to a new cache during this time.
@IntergalacticPeanutMaker : Won't the transfer of the cache line in the write-back buffer only happen when another cache requires it for read/write? Otherwise, the buffer won't be flushed while snooping right? It will probably be flushed at some other time (I don't know when) ?
I don't quite understand the meaning of "Cancel outstanding bus access request(for the write back)". My understanding of this slide is, write back buffer is treated equally as cache on that processor. And the state of cache lines in write back buffer is guaranteed to be "Modified", so if Rd/RdX is received from bus, it will be flushed to memory. Please correct me if I'm wrong, and hope some one could explain on my confusion.
@ZhuansunXt, my understanding is that the snoop controller would simply send the data in write back buffer to the requestor and memory would not respond to this request any more. From slide #33, the setting here seems to be that if some cache has a copy of requested data, that cache should service the request instead of memory. Isn't it different from what's said previously, where the dirty cache data should be flushed to memory first and then memory would service the actual request?
@zhuansunXt. That comment is referring to the fact that if the line is sitting in the write back buffer, presumably the cache has a pending request to acquire to bus to perform the write back (it's waiting in line for access to the bus). However, if the cache has to flush the line as a result of responding to coherence requests, then there's no further reason to flush the line in the write-buffer buffer -- it's already been flushed!
@TanXiaoFengSheng, what you said makes sense, so the "cancel" here means that the cache line in write-back buffer will serve the requester first, canceling transaction of flushing the data to memory temporarily, right? By the way good username :)
@kayvonf, So can I understand it in this way: the main motivation for having write-back buffer is to keep processor as busy as possible to improve throughput. And having this write-back buffer actually havs a nice side-effect: it's able to serve a requestor with modified cache data, which saves the requestor's effort to read the data from memory (and this somehow increases the cache's 'capacity', since a cache line that is supposed to be flushed can be read from a cache now).
@zhuansunXt: I wouldn't say this is an added benefit.
If a line X is in the write back buffer of cache C0, from the perspective of coherence it's another copy of the data (despite it technically not being in the case). If another cache C1 needs the line X, then the write-back buffer needs to get flushed so the requestor receives the most up-to-date data.
In a basic implementation X could be flushed to memory, and then C1 reads the up-to-date data from memory. In a more advanced implementation X could be transferred over to C1.
In either case, the presence of the write-buffer buffer does not provide new system functionality.