Hi Nilay, Yes, that is correct. There is a comment at the top of the file: src/mem/ruby/network/topologies/Mesh.py which says that very thing:
"# Makes a generic mesh assuming an equal number of cache and directory cntrls" The function ensures that only the number of dma controllers is not a multiple of the number of routers. If you know of a better way to handle this, please let me know. Brad > -----Original Message----- > From: Nilay [mailto:ni...@cs.wisc.edu] > Sent: Tuesday, January 18, 2011 9:28 PM > To: Beckmann, Brad > Cc: m5-dev@m5sim.org > Subject: RE: > > 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
