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.
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?
Secondly, does every protocol need to know the existence of a store
buffer? Or can we let just the CacheMemory interface with the store
buffer?
Overall, I guess I'm concluding that we probably can delete the current
Ruby store buffer. Do others agree?
I agree. I had chat with Derek about this, he also agrees that it is not
required in its present form.
--
Nilay
Brad
From: Steve Reinhardt [mailto:ste...@gmail.com]
Sent: Thursday, February 24, 2011 11:20 AM
To: M5 Developer List
Cc: Beckmann, Brad
Subject: Re: [m5-dev] Store Buffer
On Thu, Feb 24, 2011 at 11:08 AM, Beckmann, Brad
<brad.beckm...@amd.com<mailto:brad.beckm...@amd.com>> wrote: So we
probably don't want to pass speculative store data to the RubyPort, but
what about speculative load and store requests? I suspect we do want to
send them to the RubyPort before the speculation is confirmed. That
might require splitting stores to two separate transactions: the request
and the actual data write. Also I suspect that the RubyPort will need
to forward probes to the cpu models to allow the LSQ to maintain the
proper consistency model. If those two things end up being true, then
what is the benefit of putting the non-speculative store buffer in each
protocol, versus just in the o3 cpu model?
I'm not yet ready to advocate that is the right solution. I just want
us to think these issues thru before deciding to go down one path or the
other.
I also support the concept of thinking things through, but I'm also
happy to comment without having done that yet :-).
My gut instinct is to say that O3 already has an LSQ, so Ruby needs to
send invalidations up to the core to support the consistency model, and
if we do that there's no need for a store buffer in Ruby. I'd like to
better understand the arguments against that approach. For example, why
would we want to send stores to Ruby when they are still speculative?
Do we have real examples of systems that send the store address to the
L1 cache speculatively? If we want to fetch store data more
aggressively, wouldn't it be equivalent to generate a
prefetch-with-write-intent first, then generate the store itself only
when it commits? I think there are machines that do that.
Steve
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
