I think there are different topology file for different layouts and thus
allowing different number of controllers. For example, topology named
"MeshDirCorners" would allow a configuration with "--num-cpus 16
--num-l2caches 16 --num-dirs 4 ". This essentially places the MCs (a.k.a
dirs) at the corner of the chip.
Similarly, if disproportionate number of L2 controllers are need then
MeshClustered or MeshClusteredDirCorners topologies need to be used.
Thanks
Arka
On 01/18/2011 11:28 PM, Nilay wrote:
Brad,
I got the simulation working. It seems to me that you wrote Mesh.py under
the assumption that number of cpus = number of L1 controllers = number of
L2 controllers (if present) = number of directory controllers.
The following options worked after some struggle and some help from Arka -
./build/ALPHA_FS_MESI_CMP_directory/m5.fast ./configs/example/ruby_fs.py
--maxtick 2000000000 -n 16 --topology Mesh --mesh-rows 4 --num-dirs 16
--num-l2caches 16
--
Nilay
On Tue, January 18, 2011 10:28 am, Beckmann, Brad wrote:
Hi Nilay,
My plan is to tackle the functional access support as soon as I check in
our current group of outstanding patches. I'm hoping to at least check in
the majority of them in the next couple of days. Now that you've
completed the CacheMemory access changes, you may want to re-profile GEM5
and make sure the next performance bottleneck is routing network messages
in the Perfect Switch. In particular, you'll want to look at rather large
(16+ core) systems using a standard Mesh network. If you have any
questions on how to do that, Arka may be able to help you out, if not, I
can certainly help you. Assuming the Perfect Switch shows up as a major
bottleneck (> 10%), then I would suggest that as the next area you can
work on. When looking at possible solutions, don't limit yourself to just
changes within Perfect Switch itself. I suspect that redesigning how
destinations are encoded and/or the interface between MessageBuffer
dequeues and the PerfectSwitch wakeup, will lead to a better solution.
Brad
-----Original Message-----
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, January 18, 2011 6:59 AM
To: Beckmann, Brad
Cc: m5-dev@m5sim.org
Subject:
Hi Brad
Now that those changes to CacheMemory, SLICC and protocol files have
been pushed in, what's next that you think we should work on? I was
going
through some of the earlier emails. You have mentioned functional access
support in Ruby, design of the Perfect Switch, consolidation of stat
files.
Thanks
Nilay
_______________________________________________
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
