On Sat, 12 Mar 2011, Steve Reinhardt wrote:
On Sat, Mar 12, 2011 at 1:34 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
On Fri, 11 Mar 2011, Steve Reinhardt wrote:
Thanks for the explanation... I was expecting to see a loop on
L1DcacheMemory like before and I missed the one on system.ruby.network.
In the short run, I think the easiest way to break the cycle is to have
the
network take the RubySystem object as a parameter instead of the other way
around, then add a registerNetwork() callback on RubySystem to let the
network give the system its pointer.
There are more dependencies involved in here. RubySystem needs total memory
size, which is calculated by looping through all the directory controllers.
But the controllers themselves require RubySystem pointer.
Can't we loop through the directory controllers in python to calculate the
total size, then pass that size as a parameter to RubySystem? There's no
reason for the C++ RubySystem object to need the directory controller
pointers just to do that calculation.
It is being done in Python script. We were thinking of passing RubySystem
object to the Network. But RubySystem cannot be created before directory
controllers are created. And the reason for these changes is to pass
RubySystem object to the controllers.
I still don't understand the opposition to cache controllers moving under
RubySystem. They should logically be under RubySystem. Whenever we choose to
remove RubySystem, everything will move under system. By having controllers
under system and rest of Ruby components under RubySystem, we are creating
two paths in the graph that are running parallel to each other, even though
we have dependence between them. I would rather have a tree / directed
acyclic structure.
Yes, it's supposed to be an acyclic tree structure.
What do you mean by "cache controllers moving under RubySystem"? As
children or as parameters? They're not parameters of System now, and the
fact that they're children of System isn't related to the parameter cycle
we're trying to break.
I would like to access cache controllers from RubySystem parameter object
in C++. If we do allow such access, then we would not have any cycle in
the graph. We only need to create controllers, then network and then
RubySystem in Python. If controllers are visible to RubySystem as members
of the RubySystem parameter object, then we can create the list of cache
memories by probing each controller object.
Nilay
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
