It sounds like we are in agreement here, but I just want to make sure we clarify one item. I don't believe simply checking the coherence permissions at commit time can sufficiently support stronger consistency models like SC/TSO. Instead you need to really need to know whether you've ever lost the block since the speculative instruction read it. Therefore, Ruby really does need to forward invalidations to the CPU.
It sounded like from your responses that you understand that as well, but I just wanted to make the point clear. Brad From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: Friday, February 25, 2011 10:29 AM To: M5 Developer List Subject: Re: [m5-dev] Store Buffer This sounds right. Ruby does need to forward invalidations to the CPU since some models (including O3) will need to do internal invalidations/flushes to maintain consistency. Others can choose to do it other ways (e.g., by querying the L1 at commit as you suggest), but they have the option of ignoring the forwarded invalidations, so that's not a problem. Steve On Fri, Feb 25, 2011 at 9:07 AM, Arkaprava Basu <[email protected]<mailto:[email protected]>> wrote: In sum, I think we all agree that Ruby is going to handle *only non-speculative stores*. M5 CPU model(s) handles all of speculative and non-speculative stores that are *yet to be revealed to the memory sub-system*. To make it clearer, as I understand, we now have following: 1. All store buffering (speculative and non-speculative) is handled by CPU model in M5. 2. Ruby needs to forward intervention/invalidation received at L1 cache controller to the CPU model to let it take appropriate action to guarantee required memory consistency guarantees (e.g t may need to flush pipeline). OR CPU models need to check coherence permission at L1 cache at the commit time to know if intervening writes has happened or not (might be required to implement stricter model like SC). I think we need to provide one of the functionality from Ruby side to allow the second condition above. Which one to provide depends upon what M5 CPU models wants to do to guarantee consistency. Please let me know if you disagree or if I am missing something. Thanks Arka On 02/24/2011 05:22 PM, Beckmann, Brad wrote: So I think Steve and I are in agreement here. We both agree that both speculative and non-speculative store buffers should be on the CPU side of the RubyPort interface. I believe that was the same line that existed when Ruby tied to Opal in GEMS. I believe the non-speculative store buffer was only a feature used when Opal was not attached, and it was just the simple SimicsProcessor driving Ruby. The sequencer is a separate issue. Certain functionality of the sequencer can probably be eliminated in gem5, but I think other functionality needs to remain or at least be moved to some other part of Ruby. The sequencer performs a lot of protocol independent functionality including: updating the actual data block, performing synchronization with respect to the cache memory, translating m5 packets to ruby requests, checking for per-cacheblock deadlock, and coalescing requests to the same cache block. The coalescing functionality can probably be eliminated, but I think the other functionality needs to remain. Brad From: [email protected]<mailto:[email protected]> [mailto:[email protected] ] On Behalf Of Steve Reinhardt Sent: Thursday, February 24, 2011 1:52 PM To: M5 Developer List Subject: Re: [m5-dev] Store Buffer On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish <[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]>> wrote: On Thu, 24 Feb 2011, Beckmann, Brad wrote: Steve, I think we are in agreement here and we may just be disagreeing with the definition of speculative. From the Ruby perspective, I don't think it really matters...I don't think there is difference between a speculative store address request and a prefetch-with-write-intent. Also we agree that probes will need to be sent to O3 LSQ to support the consistency model. My point is that if we believe this functionality is required, what is the extra overhead of adding a non-speculative store buffer to the O3 model as well? I think that will be easier than trying to incorporate the current Ruby non-speculative store buffer into each protocol. I don't know the O3 LSQ model very well, but I assume it buffers both speculative and non-speculative stores. Are there two different structures in Ruby for that? I think the general issue here is that the dividing line between "processor" and "memory system" is different in M5 than it was with GEMS. with M5 assuming that write buffers, redundant request filtering, etc. all happens in the "processor". For example, I know I've had you explain this to me multiple times already, but I still don't understand why we still need Ruby sequencers either :-). Brad, I raise the same point that Arka raised earlier. Other processor models can also make use of store buffer. So, why only O3 should have a store buffer? Nilay, I think that's a different issue... we're not saying that other CPU models can't have store buffers, but in practice, the simple CPU models block on memory accesses so they don't need one. If the inorder model wants to add a store buffer (if it doesn't already have one), it would be an internal decision for them whether they want to write one from scratch or try to reuse the O3 code. There are already some shared structures in src/cpu like branch predictors that can be reused across CPU models. So in other words we need to decide first where the store buffer should live (CPU or memory system) and then we can worry about how to reuse that code if that's useful. Steve _______________________________________________ m5-dev mailing list [email protected]<mailto:[email protected]> http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected]<mailto:[email protected]> http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
