> On July 5, 2012, 1:10 a.m., Andreas Hansson wrote:
> > src/mem/ruby/system/MemoryControl.hh, line 93
> > <http://reviews.gem5.org/r/1287/diff/1/?file=27608#file27608line93>
> >
> >     I thought this was a single channel controller?

There are other memory controllers that inherit from this base class that 
implement multi-channel controllers.


> On July 5, 2012, 1:10 a.m., Andreas Hansson wrote:
> > src/mem/ruby/system/RubyMemoryControl.cc, line 677
> > <http://reviews.gem5.org/r/1287/diff/1/?file=27612#file27612line677>
> >
> >     Could this possibly work? What if there are message in the queues?

I actually added this drain function to the memory controll several months ago 
(8937:225590437eb2).  This function was just copied from that patch.  The 
reason for immediate descheduling of the mem cntrl event is that the cntrl is 
clock driven and uses the event as a repeatable tick.  If I didn't deschedule 
it, it would continue forever.

That being said, your concerns are justified.  The RubyPort is responsible for 
ensuring ruby drains properly, but it is not clear to me that there could be a 
corner case where ruby's drain can complete because the mem cntrl already went 
to sleep.  In practice I haven't seen that problem and it is a situation that 
should be obvious when it occurs.  When it does, we'll fix it appropriately.  
However, I don't want to fix a bug that I have yet to see.  Especially because 
the memory controller code is not my speciality.


- Brad


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1287/#review3048
-----------------------------------------------------------


On July 10, 2012, 4:21 p.m., Brad Beckmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1287/
> -----------------------------------------------------------
> 
> (Updated July 10, 2012, 4:21 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> Changeset 9075:3b3c9db76ebc
> ---------------------------
> ruby: memory controllers now inherit from an abstract "MemoryControl" class
> 
> 
> Diffs
> -----
> 
>   src/mem/ruby/system/MemoryControl.hh 
> 7dee77da691b5ec4217685b99c621c36dfbea4c6 
>   src/mem/ruby/system/MemoryControl.cc 
> 7dee77da691b5ec4217685b99c621c36dfbea4c6 
>   src/mem/ruby/system/MemoryControl.py 
> 7dee77da691b5ec4217685b99c621c36dfbea4c6 
>   src/mem/ruby/system/RubyMemoryControl.hh PRE-CREATION 
>   src/mem/ruby/system/RubyMemoryControl.cc PRE-CREATION 
>   src/mem/ruby/system/RubyMemoryControl.py PRE-CREATION 
>   src/mem/ruby/system/SConscript 7dee77da691b5ec4217685b99c621c36dfbea4c6 
>   src/mem/slicc/symbols/StateMachine.py 
> 7dee77da691b5ec4217685b99c621c36dfbea4c6 
> 
> Diff: http://reviews.gem5.org/r/1287/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Brad Beckmann
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to