From AMD's perspective, we have deprecated our usage of RubyMemoryControl and we are using the new Memory Controllers with the port interface.
That being said, I completely agree with Joel that the packet queue finite invisible buffer limit of 100 needs to go! As you know, we tried very hard several months ago to essentially make this a infinite buffer, but Andreas would not allow us to check it in. We are going to post that patch again in a few weeks when we post our GPU model. Our GPU model will not work unless we increase that limit. Andreas you keep arguing that if you exceed that limit, that something is fundamentally broken. Please keep in mind that there are many uses of gem5 beyond what you use it for. Also this is a research simulator and we should not restrict ourselves to what we think is practical in real hardware. Finally, the fact that the finite limit is invisible to the producer is just bad software engineering. I beg you to please allow us to remove this finite invisible limit! Brad -----Original Message----- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson Sent: Tuesday, September 22, 2015 6:35 AM To: Andreas Hansson; Default; Joel Hestness Subject: Re: [gem5-dev] Review Request 3116: ruby: RubyMemoryControl delete requests > On Sept. 21, 2015, 8:42 a.m., Andreas Hansson wrote: > > Can we just prune the whole RubyMemoryControl rather? Has it not been > > deprecated long enough? > > Joel Hestness wrote: > Unless I'm overlooking something, for Ruby users, I don't see other > memory controllers that are guaranteed to work. Besides RubyMemoryControl, > all others use a QueuedSlavePort for their input queues. Given that Ruby > hasn't added complete flow control, PacketQueue size restrictions can be > exceeded (triggering the panic). This occurs infrequently/irregularly with > aggressive GPUs in gem5-gpu, and appears difficult to fix in a systematic way. > > Regardless of the fact we've deprecated RubyMemoryControl, this is a > necessary fix. No memory controller is using QueuedSlaavePort for any _input_ queues. The DRAMCtrl class uses it for the response _output_ queue, that's all. If that is really an issue we can move away from it and enfore an upper bound on responses by not accepting new requests. That said, if we hit the limit I would argue something else is fundamentally broken in the system and should be addressed. In any case, the discussion whether to remove RubyMemoryControl or not should be completely decoupled. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3116/#review7226 ----------------------------------------------------------- On Sept. 16, 2015, 6:07 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3116/ > ----------------------------------------------------------- > > (Updated Sept. 16, 2015, 6:07 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11093:b3044de6ce9c > --------------------------- > ruby: RubyMemoryControl delete requests > > Changes to the RubyMemoryControl removed the dequeue function, which > deleted MemoryNode instances. This results in leaked MemoryNode > instances. Correctly delete these instances. > > > Diffs > ----- > > src/mem/ruby/structures/RubyMemoryControl.cc 62e1504b9c64 > > Diff: http://reviews.gem5.org/r/3116/diff/ > > > Testing > ------- > > Compiled gem5.debug with --without-tcmalloc. Ran large tests with Valgrind. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
