On Sun, 26 Oct 2014, Steve Reinhardt wrote:
On Sun, Oct 26, 2014 at 6:35 AM, Nilay Vaish <[email protected]> wrote:
Everything you mention is already in place.
Great, glad to hear it. Sorry I don't keep up with the details of what's
going on inside of Ruby, and it's been quite a while since I've had an
in-depth discussion with Brad on this.
The problem is with reads since we can hit stale data before we hit the
actual data.
Can you elaborate? I was a little loose in saying it's just addresses &
data, of course you need to condition that on validity too. But other than
avoiding explicitly invalidated blocks, what do you mean by "stale data"?
I doubt your claim that it would be easy to support functional accesses if
we re-design. In my opinion, every protocol necessarily needs to provide
some functionality that reasons about the states in different controllers
and decides which controller / buffer holds the current data. As Joel
mentions, it is hard to write a coherence protocol that is coherent about
the data. I hardly think people would be willing to write code that
reasons about multiple controller states together.
I think that for functional accesses the only state distinction that
matters is valid vs. invalid. If there are specific cases where this is
insufficient, I'd like to hear more details. As I said, the interaction
between functional accesses and consistency models is pretty murky, and it
would be nice to deal with that issue (where it matters) outside of the
functional accesses themselves. A specific example would be helpful, I
think.
Marc Orr asked me the same question last year. I am pasting the examples
I gave him:
a. the data in the message is stale, but the sender does not know about
it. Take a look at the MESI CMP directory protocol. In the case when an L1
controller (A) sends a PUTX to the L2 controller, it is possible that the
L2 controller has already transferred the ownership to some L1 controller
(B). In this case, it is possible that there are two message buffers that
contain messages from A and B to the L2 controller, but it is message from
B which has the 'right' data.
b. no data is present in the message and the receiver will infer that the
data it has is correct since the message did not have any data.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
