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. Thanks, Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
