Hi Steve,
Your workaround solved the issue. Thanks for the quick and easy solution!
Stijn
Op 26/09/2012 17:08, Steve Reinhardt schreef:
Hi Stijn,
This is a confusing case. Based on what you're describing (and thanks
for the thorough description btw!), my hypothesis of what's happening
is that you are successfully creating a single workload SimObject, but
that that single object is getting added to the list of the CPU
object's children twice. Thus whenever the code walks the SimObject
hierarchy tree, it processes that workload object twice. That's why
you see it printed out twice in the config.ini file, and why it has
regStats() called on it twice.
I will further hypothesize that the real problem has nothing to do
with SMT or workloads, but has to do with how vector param assignment
interacts with hierarchy parent/child relationships. As you probably
already know, if you assign an unparented SimObject to a parameter
of another SimObject, the former object automatically becomes a child
of the latter one. However, if the former object already had a
parent, then it does not get reparented. This works well for scalar
parameters, and typically works OK for vector parameters where all the
objects in the assigned vector either do or do not have parents.
However, things get weird when some of the objects in the vector have
parents and some do not. I think you're finding that the problems get
weirder still when you have multiple references to the same object in
the vector, such that initially none of the objects in the vector has
a parent, but as you assign a parent to the first one then that
automatically assigns a parent to other objects.
I could rant at length about the complexity of defining consistent
semantics for vector parameter assignment (this is not the first time
it's created headaches, though this is a novel twist on the issue).
However, I think for your case, a relatively easy workaround would be
to explicitly make the workload object a child of the cpu object
before doing the assignment to the workload parameter. So doing
something like:
system.cpu[i].workload = multiprocesses[0]
system.cpu[i].workload = [ multiprocesses[0]] * int(numThreads)
might be enough.
Let me know if that works...
Steve
On Wed, Sep 26, 2012 at 4:41 AM, Stijn Eyerman
<stijn.eyer...@elis.ugent.be <mailto:stijn.eyer...@elis.ugent.be>> wrote:
Hi,
I want to simulate a multi-threaded program on a multicore
supporting SMT. I used m5threads to make some PARSEC benchmarks
run in SE mode. They run fine if I don't use SMT (i.e., one thread
per core).
To enable a multi-threaded program to run on multiple cores, the
workload of each core is set to the same process:
se.py: system.cpu[i].workload = multiprocesses[0]
This creates one workload SimObject (as seen in config.ini) as a
child of cpu0, and all cores' workloads point to that object.
To enable multiple threads on one core, I set the numThreads
parameter, and assign multiple workloads per core (which works
fine in multiprogrammed mode):
se.py: system.cpu[i].workload = [ multiprocesses[0]] * int(numThreads)
However, for two-way SMT (numThreads=2), two workload SimObjects
are created, both children of cpu0, and both with the same name.
They both refer to the same process.
config.ini:
...
[system.cpu0]
type=DerivO3CPU
children=dcache dtb fuPool icache itb tracer workload1 workload1
BTBEntries=4096
...
wbWidth=8
workload=system.cpu0.workload1 system.cpu0.workload1
dcache_port=system.cpu0.dcache.cpu_side
...
[system.cpu0.workload1]
type=LiveProcess
cmd=blackscholes 4 in_16.txt prices.txt
cwd=
...
[system.cpu0.workload1]
type=LiveProcess
cmd=blackscholes 4 in_16.txt prices.txt
cwd=
...
When this configuration is simulated, it gives an error, because
regStats() is executed twice on the same process, creating
duplicate statistics names.
When I give only one process as a workload (as in the non-SMT
case), then the second context of each core is not available for
the multi-threaded program, so that doesn't solve the problem.
It seems that everything is set correctly, except for the fact
that the workload object is now duplicated in the configuration
tree. For the simulation itself, both thread contexts point to the
same process, which is correct. But when the statistics are
initialized, it goes over this process twice, which causes the error.
How can I eliminate this duplication?
And how is it done in the non-SMT mode? In that case, the same
process is assigned to multiple cores, but still only one workload
object is created. Is it checked somewhere that workloads could be
the same and that only one object is created? Then maybe it
doesn't check this if multiple processes to one CPU are assigned?
I've tried to dig into the configuration tree creation code, but
this is quite hard to understand due to the mixture of Python and C++.
Does anyone have an idea?
Thanks,
Stijn
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org <mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
