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. 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. Steve On Thu, Oct 23, 2014 at 5:36 AM, Nilay Vaish via gem5-dev <[email protected] > wrote: > > > > On Oct. 22, 2014, 10:31 p.m., Andreas Hansson wrote: > > > src/mem/ruby/system/RubyPort.cc, line 323 > > > <http://reviews.gem5.org/r/2466/diff/1/?file=42342#file42342line323> > > > > > > Why has this changed? > > Because I want the system's copy to be the actual copy and ruby's copy > to be secondary. > > > On Oct. 22, 2014, 10:31 p.m., Nilay Vaish wrote: > > > I do not understand what the patch is doing, and why we do not rely on > doing things as before with the System being responsible for the memories > and the backing stores. This memory does not even have to be connected to > anything in the physical sense. > > > > > > Could you provide some background as to the code, and why the code > that is there at the moment does not fit the bill? > > Andreas, I think Joel has answered your question in sufficient detail. > > I would add some more information for you. Remember that Ruby currently > in the repo > has a copy of the memory, different from the system's copy (system's copy > is not > allocated in SE mode). I have not been able to convince people that we > should work > with a single copy of the memory. With this patch, the copy of the memory > would be > explicitly visible in the configuration. And with the later patch that > changes memory > controller's interface, we would move towards the system's copy being the > actual copy > of memory (in the mainline repo), and ruby's copy only for the purpose > Joel describes. > > > - Nilay > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2466/#review5424 > ----------------------------------------------------------- > > > On Oct. 21, 2014, 10:01 p.m., Nilay Vaish wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.gem5.org/r/2466/ > > ----------------------------------------------------------- > > > > (Updated Oct. 21, 2014, 10:01 p.m.) > > > > > > Review request for Default. > > > > > > Repository: gem5 > > > > > > Description > > ------- > > > > Changeset 10497:587c77ab8adc > > --------------------------- > > ruby: provide a second copy of the memory > > This memory is required in some cases. It can be enabled by invoking > > the option --access-phys-mem > > > > > > Diffs > > ----- > > > > configs/ruby/Ruby.py ffe6ab7141ab > > src/mem/ruby/system/DMASequencer.hh ffe6ab7141ab > > src/mem/ruby/system/DMASequencer.cc ffe6ab7141ab > > src/mem/ruby/system/RubyPort.hh ffe6ab7141ab > > src/mem/ruby/system/RubyPort.cc ffe6ab7141ab > > src/mem/ruby/system/RubySystem.py ffe6ab7141ab > > src/mem/ruby/system/Sequencer.py ffe6ab7141ab > > src/mem/ruby/system/System.hh ffe6ab7141ab > > src/mem/ruby/system/System.cc ffe6ab7141ab > > > > Diff: http://reviews.gem5.org/r/2466/diff/ > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Nilay Vaish > > > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
