Why cancel the outstanding bus access request (for the write back)? The data is still stale, so it should be flush to memory, right?
eourcs
I think this is more of an implementation detail. The write-back buffer may be set up to write to memory every X number of cycles, instead of in response to a signal, and so there would be no need to flush to memory immediately. We would still be guaranteed correctness since every request would check the write-back buffer first.
crabcake
@bochet I think it depends the request is a PrRd or PrWr. If it is a PrWr, there is no need for this outstanding bus access request to continue because the data in the memory will be dirty anyway. If it is a PrWr, there is still no need if the later cache with shared state of this data is responsible for response this data in future. However, in this situation, I think there is a need for this outstanding bus access request to continue if the memory is responsible for response the later shared data.
Why cancel the outstanding bus access request (for the write back)? The data is still stale, so it should be flush to memory, right?
I think this is more of an implementation detail. The write-back buffer may be set up to write to memory every X number of cycles, instead of in response to a signal, and so there would be no need to flush to memory immediately. We would still be guaranteed correctness since every request would check the write-back buffer first.
@bochet I think it depends the request is a PrRd or PrWr. If it is a PrWr, there is no need for this outstanding bus access request to continue because the data in the memory will be dirty anyway. If it is a PrWr, there is still no need if the later cache with shared state of this data is responsible for response this data in future. However, in this situation, I think there is a need for this outstanding bus access request to continue if the memory is responsible for response the later shared data.