On Sat, 25 Oct 2014, Steve Reinhardt wrote:
Thanks to everyone, particularly Joel, for the discussion.
Joel makes a good case for having the option of a second copy of memory for
debugging and development purposes, and at first glance, Nilay's patch
seems reasonable to me. However, the backing store idea enforces a
sequentially consistent memory model, so in the long run I don't see that
it's a viable universal solution.
I do think that Ruby should do a better job of supporting functional
accesses. Brad and I have had numerous discussions about Ruby functional
memory in the past, but long enough ago that I don't recall his exact
positions, only that we didn't always see eye to eye :). I think that if
functional accesses had been designed into Ruby from the beginning, it
would not be so bad. All you really need is a protocol-independent
interface to associate addresses with data for each structure that could
hold memory-system data (e.g., a cache or the payload of a message). Then
the functional access can do an exhaustive traversal of the memory system
including caches, router buffers, links, anywhere data might be
sitting---looking for data that is associated with the access address.
Functional reads are pretty easy; you just traverse the memory system and
return the data at the first match you found. Functional writes require
you to traverse the whole system and update the data at every match.
Everything you mention is already in place. The problem is with reads
since we can hit stale data before we hit the actual data.
It's hard to define what this means in terms of the consistency protocol,
but my opinion is that, to the first order, it doesn't matter. For writes,
since we update all the copies, then it should just work regardless of what
happens. The read part is a little more sketchy, but for things like
SE-mode accesses, it should be OK in practice... for example, if there's
some kind of data race on your write() buffer then you probably have bigger
issues.
So if I were re-designing Ruby from scratch, I don't think that supporting
functional accesses would be a big deal. Retroactively adding that
capability to Ruby along with all the existing protocols could be a pretty
big job though. I honestly don't know Ruby well enough to say, but it's
clearly a big enough job that I have not been able to convince Brad to do
it ;). But I think this is the model we should work toward for improving
Ruby functional accesses, and not rely on having a separate functional
memory for that.
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.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
