Added a subject. Gabe
Beckmann, Brad wrote: > 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 > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
