This is my understanding of the condition. The script does execute "system.cpu[i].workload = process", but it also executes "switch_cpus[i].workload = testsys.cpu[i].workload", which means that workload can potentially have two parents. If it so happens that when you call root.descendents() that you get switch_cpus first, then you will add workload as a child of switch_cpus.
> > On Tue, Jan 25, 2011 at 12:31 PM, Steve Reinhardt <[email protected]>wrote: > >> 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 <[email protected]>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 >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
