Re: [m5-dev] (no subject)
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 20 -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
Re: [m5-dev] (no subject)
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 b etter 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
Re: [m5-dev] (no subject)
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 20 -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
Re: [m5-dev] (no subject)
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 20 -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
Re: [m5-dev] (no subject)
Hello, I don't mean to disrupt this conversation but for archiving purposes can we put a relevant title in the subject of the m5-dev emails? Myself and another student at UM are trying to spin up on the Ruby/M5 stuff but it makes it harder when an email doesn't have a subject. Again, dont mean to be a stickler, just a friendly M5 suggestion :) -Korey On Tue, Jan 18, 2011 at 9:58 AM, Nilay Vaish ni...@cs.wisc.edu wrote: 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 -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] (no subject)
I agree, but at times I find it difficult to come up with some apt subject. -- Nilay On Wed, 19 Jan 2011, Korey Sewell wrote: Hello, I don't mean to disrupt this conversation but for archiving purposes can we put a relevant title in the subject of the m5-dev emails? Myself and another student at UM are trying to spin up on the Ruby/M5 stuff but it makes it harder when an email doesn't have a subject. Again, dont mean to be a stickler, just a friendly M5 suggestion :) -Korey On Tue, Jan 18, 2011 at 9:58 AM, Nilay Vaish ni...@cs.wisc.edu wrote: 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 -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
