An object can only have one parent, and the implicit setting of the parent on parameter assignment is only supposed to occur if the RHS object does not already have a parent. So that second assignment shouldn't affect the process object's parent pointer. Plus if either one of these assignments actually sets the parent pointer, then it shouldn't be getting set again in adoptOrphanParams() (because it won't be an orphan).
Obviously something's not working the way it's supposed to, but that's how it's supposed to work... Steve On Tue, Jan 25, 2011 at 1:29 PM, Richard Strong <[email protected]> wrote: > 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 > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
