This is pretty interesting. I hadn't thought that it would matter, but if an unparented object is listed as a parameter to more than one other object then the one that it gets parented too will depend on the order you call adoptOrphanParams(). You're absolutely right that you don't want to depend on that order.
In fact, your script is *supposed* to set a definite parent for each SimObject in your configuration; it just usually happens implicitly so people aren't always aware that this is happening. See http://m5sim.org/wiki/index.php/Simulation_Scripts_Explained#The_configuration_hierarchy . The adoptOrphanParams() code was added relatively recently to deal with some seemingly obscure cases where the implicit method wasn't working right. I'm curious how this ended up happening for your workload objects. In the existing se.py, line 154: system.cpu[i].workload = process should set cpu[i] as the parent of the process object if the process object doesn't already have a parent. Maybe what we really need to do is print a notification in adoptOrphanParams() when a parent gets set there, so people can see what's happening there and notice if it looks wrong. Steve On Tue, Jan 25, 2011 at 12:02 PM, Richard Strong <rstr...@cs.ucsd.edu>wrote: > Hi all, > > I came across some indeterminism that causes problems. Yesterday I had a > bug that workload pagetables would not unserialize if I added an l2 cache, > but would if I had only a L1 cache. The culprit appears to be > src/python/m5/simulate.py, the portion that looks for oprhans to add to > objects in the system. The problem was that the workload was getting > associated with system.switch_cpus as opposed to system.cpu, and M5 could > not find workload checkpoint information for system.switch_cpus.workload. My > fix, is given below and just puts the paths in sorted order. This however > relies on the fact that cpu occurs alphabetically before switch_cpus, which > doesn't seem like a permanent fix. The end solution would be to be able to > set a definite parent for each workload, so it is not treated like an > orphan. > > Thanks, > Rick > > diff --git a/src/python/m5/simulate.py b/src/python/m5/simulate.py > --- a/src/python/m5/simulate.py > +++ b/src/python/m5/simulate.py > @@ -58,7 +58,7 @@ > > # Make sure SimObject-valued params are in the configuration > # hierarchy so we catch them with future descendants() walks > - for obj in root.descendants(): obj.adoptOrphanParams() > + for obj in sorted(root.descendants(), key=lambda o: o.path()): > obj.adoptOrphanParams() > > # Unproxy in sorted order for determinism > for obj in root.descendants(): obj.unproxyParams() > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
