> On Feb. 5, 2015, 8:25 a.m., Andreas Hansson wrote: > > src/mem/ruby/system/RubySystem.py, line 51 > > <http://reviews.gem5.org/r/2627/diff/1/?file=43431#file43431line51> > > > > I find the description rather misleading. > > > > In essence it is not the case of bypassing the interconnect, it is more > > a case of duplicating the memory, and ignoring the "normal" one. > > > > Thinking about it, why do we not just use the actual memory, but do so > > by faking it through system->getPhysMem().access(...) > > Jason Power wrote: > I've updated this description. I don't follow your last statement, though. > > Andreas Hansson wrote: > Why do we need this additional backing store, and why do we not simply > bypass the interconnect and use C++ magic, going through the > system->getPhysMem(), but to the same backing store we would have used had we > gone through the interconnect. Perhaps I am missing something...
Well, on the one hand, this patch is just fixing the support Nilay added in patch 10525:77787650cbb (http://reviews.gem5.org/r/2466/). IIRC, that patch was added after Nilay removed this support although both gem5-gpu and AMD depends on it. It turns out that patch was totally broken, and without this patch that support didn't work. I'd like to get this patch pushed in since it's fixing something that we depend on. On the other hand, if I follow what you're saying, yes, there is a much better way to provide this support. At the high level all we want is to use Ruby for timing and a backing store for the data. It's very hard to implement a cache coherence protocol that deals with data correctly, and the backing store is useful both in debugging protocols while building them and for protocols with subtle bugs in how data is handled. Does this make sense? > On Feb. 5, 2015, 8:25 a.m., Andreas Hansson wrote: > > src/mem/ruby/system/DMASequencer.cc, line 216 > > <http://reviews.gem5.org/r/2627/diff/1/?file=43429#file43429line216> > > > > Should this really be functional, or should it just be "access"? > > Jason Power wrote: > I can make this change. What is the difference between access() and > functionalAccess()? When should one be used and not the other? I might have > missed it, but I can't find any guide to this on the wiki or in the code. > > Also, do you want me to go back through and make this update in the > RubyPort as well? > > Andreas Hansson wrote: > functional -> do not change any state (only read/write and update data), > should only be used by send/recvFunctional imho > > normal -> anything from atomic or timing where we also need to deal with > Swap, LLSC etc and the state (in addition to data) changes > > I think in all these cases we should use access() Gotcha. Fixed. - Jason ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2627/#review5828 ----------------------------------------------------------- On Feb. 5, 2015, 3:38 p.m., Jason Power wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2627/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2015, 3:38 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10681:b2dc4aee1a0d > --------------------------- > Ruby: Update backing store option to propagate through to all RubyPorts > > Previously, the user would have to manually set access_backing_store=True > on all RubyPorts (Sequencers) in the config files. > Now, instead there is one global option that each RubyPort checks on > initialization. > > > Diffs > ----- > > configs/ruby/Ruby.py 7639c17357dc > src/mem/ruby/system/DMASequencer.hh 7639c17357dc > src/mem/ruby/system/DMASequencer.cc 7639c17357dc > src/mem/ruby/system/RubyPort.cc 7639c17357dc > src/mem/ruby/system/RubySystem.py 7639c17357dc > src/mem/ruby/system/Sequencer.py 7639c17357dc > src/mem/ruby/system/System.hh 7639c17357dc > src/mem/ruby/system/System.cc 7639c17357dc > > Diff: http://reviews.gem5.org/r/2627/diff/ > > > Testing > ------- > > > Thanks, > > Jason Power > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
