I was interested in the different controllers with respect to timings, and so I read up on ARM's CoreLink controllers. Though they do more than just cache controllers (though the cache controllers can be either in the CPU itself or a separate component), the website has a lot more information and goes very in depth about the specification itself.
The whole section is great to read how these things work in hardware.
Sherry
For "2. cancel outstanding bus access request" in the slide, which means all the following requests which want to visit the write-back buffer like requests which want to read the line or the requests which want to flush the line into the memory?
BigFish
Can someone further explain the the second point "Cancel outstanding bus access request"?
yuel1
I think the "Cancel outstanding bus access request" means we no longer need to flush this line out to main memory, since it now exists in another processor's cache line.
I do wonder though, does this mean once there has been a write-back buffer match, we can, in addition to cancelling the write back request, also remove that line from the write-back buffer?
afa4
I agree with @yuel1. Since the cache line now resides in some other processor's cache, we can cancel the outstanding flush request and I think, it should also be safe to further remove this cache line from the write-back buffer .
Sherry
@yuel1 If the line in the write-back buffer has already in another processor's cache line, does it mean that line has already been updated to memory, otherwise how another processor get that line? Am I right?
yuel1
@Sherry So I'm making the assumption that if anything is sitting in the write-back buffer, it is the most up-to-date version of data that sits at that address. Assuming we flush the write-back buffer when another cache wants access to that line, we can never end up in that situation.
I was interested in the different controllers with respect to timings, and so I read up on ARM's CoreLink controllers. Though they do more than just cache controllers (though the cache controllers can be either in the CPU itself or a separate component), the website has a lot more information and goes very in depth about the specification itself.
http://www.arm.com/products/system-ip/controllers/index.php
One interesting thing about the cache controller itself is that it does not have the snooping hardware itself, and in fact it would have to be done in software to maintain coherence between caches (as found http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0329l/Chdcjfia.html )
The whole section is great to read how these things work in hardware.
For "2. cancel outstanding bus access request" in the slide, which means all the following requests which want to visit the write-back buffer like requests which want to read the line or the requests which want to flush the line into the memory?
Can someone further explain the the second point "Cancel outstanding bus access request"?
I think the "Cancel outstanding bus access request" means we no longer need to flush this line out to main memory, since it now exists in another processor's cache line.
I do wonder though, does this mean once there has been a write-back buffer match, we can, in addition to cancelling the write back request, also remove that line from the write-back buffer?
I agree with @yuel1. Since the cache line now resides in some other processor's cache, we can cancel the outstanding flush request and I think, it should also be safe to further remove this cache line from the write-back buffer .
@yuel1 If the line in the write-back buffer has already in another processor's cache line, does it mean that line has already been updated to memory, otherwise how another processor get that line? Am I right?
@Sherry So I'm making the assumption that if anything is sitting in the write-back buffer, it is the most up-to-date version of data that sits at that address. Assuming we flush the write-back buffer when another cache wants access to that line, we can never end up in that situation.