[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. *
Re: [m5-dev] Functional Interface in Ruby
It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay On Mon, 7 Mar 2011, Beckmann, Brad wrote: Hi Nilay, Please excuse the slow response. I've been meaning to reply to this email for a few days. Absolutely, we will need to maintain some sort of list of all cachememory and directorymemory objects to make the functional access support work. However, I'm not sure if we'll need to modify the protocol python files. Instead, could we create a list of these objects through their c++ constructors similar to how the SimObject list is created? Also, I know the line between the RubyPort and Sequencer is quite blurry, but is there a particular reason to push the functional access support into the Sequencer? It seems that the RubyPort would be a more natural location. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Friday, March 04, 2011 9:49 AM To: Beckmann, Brad Cc: m5-dev@m5sim.org Subject: Functional Interface in Ruby I have been thinking about how to make Ruby support functional accesses. It seems some where we will have to add support so that either RubyPort or Sequencer can view all other caches. I am currently leaning towards adding it to the sequencer. I think this can be done by editing protocol files in configs/ruby. And then RubyPort can pass on functional accesses to the Sequencer, which will look up all the caches and take the correct action. I think this can be made to work. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
Sorry I missed this thread... I just read Nilay's response about python issues and he pointed me over here. One thing we should think about is that we really only want the caches within a single system to be flushed at once... I know that it's unlikely that anyone will want to model two systems with detailed memory models at once, and I vaguely recall there were other issues with Ruby not really supporting multiple instances of itself, but I don't want to see us make things less modular than they already are. The m5 idiom for doing this is: - add a parameter to each cache/controller/whatever we want to track like this: system = Param.System(Parent.any, system object) - add a method to the System object like registerCache(Cache *c) that adds c to the system object's list of caches - Have each cache constructor call p-system-registerCache(this) to register itself Would something like this work for what you're trying to do? Steve On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish ni...@cs.wisc.edu wrote: It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay On Mon, 7 Mar 2011, Beckmann, Brad wrote: Hi Nilay, Please excuse the slow response. I've been meaning to reply to this email for a few days. Absolutely, we will need to maintain some sort of list of all cachememory and directorymemory objects to make the functional access support work. However, I'm not sure if we'll need to modify the protocol python files. Instead, could we create a list of these objects through their c++ constructors similar to how the SimObject list is created? Also, I know the line between the RubyPort and Sequencer is quite blurry, but is there a particular reason to push the functional access support into the Sequencer? It seems that the RubyPort would be a more natural location. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Friday, March 04, 2011 9:49 AM To: Beckmann, Brad Cc: m5-dev@m5sim.org Subject: Functional Interface in Ruby I have been thinking about how to make Ruby support functional accesses. It seems some where we will have to add support so that either RubyPort or Sequencer can view all other caches. I am currently leaning towards adding it to the sequencer. I think this can be done by editing protocol files in configs/ruby. And then RubyPort can pass on functional accesses to the Sequencer, which will look up all the caches and take the correct action. I think this can be made to work. 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] Functional Interface in Ruby
Forgot to mention that this is how we handle registering all the thread contexts within a system... you can look at that code (in the CPU models and in System) for an example. On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt ste...@gmail.com wrote: Sorry I missed this thread... I just read Nilay's response about python issues and he pointed me over here. One thing we should think about is that we really only want the caches within a single system to be flushed at once... I know that it's unlikely that anyone will want to model two systems with detailed memory models at once, and I vaguely recall there were other issues with Ruby not really supporting multiple instances of itself, but I don't want to see us make things less modular than they already are. The m5 idiom for doing this is: - add a parameter to each cache/controller/whatever we want to track like this: system = Param.System(Parent.any, system object) - add a method to the System object like registerCache(Cache *c) that adds c to the system object's list of caches - Have each cache constructor call p-system-registerCache(this) to register itself Would something like this work for what you're trying to do? Steve On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish ni...@cs.wisc.edu wrote: It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay On Mon, 7 Mar 2011, Beckmann, Brad wrote: Hi Nilay, Please excuse the slow response. I've been meaning to reply to this email for a few days. Absolutely, we will need to maintain some sort of list of all cachememory and directorymemory objects to make the functional access support work. However, I'm not sure if we'll need to modify the protocol python files. Instead, could we create a list of these objects through their c++ constructors similar to how the SimObject list is created? Also, I know the line between the RubyPort and Sequencer is quite blurry, but is there a particular reason to push the functional access support into the Sequencer? It seems that the RubyPort would be a more natural location. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Friday, March 04, 2011 9:49 AM To: Beckmann, Brad Cc: m5-dev@m5sim.org Subject: Functional Interface in Ruby I have been thinking about how to make Ruby support functional accesses. It seems some where we will have to add support so that either RubyPort or Sequencer can view all other caches. I am currently leaning towards adding it to the sequencer. I think this can be done by editing protocol files in configs/ruby. And then RubyPort can pass on functional accesses to the Sequencer, which will look up all the caches and take the correct action. I think this can be made to work. 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] Functional Interface in Ruby
Great. It sounds like we are thinking of a similar solution. Just one thing I want to point out is AbstractController may not be the right place to build the list. As you know, sometimes a controller may manage multiple cachememory objects and other controllers may not manage any cachememory or directorymemory objects. Instead, you may want to consider creating a separate RubyStorage class that builds the list from which both CacheMemory and DirectoryMemory inherit. I'll leave it up to you to decide which is easier. Also we don't want to further inhibit ourselves from creating multiple Ruby systems in the same simulation. (I understand there may be other issues that currently prevent us from doing that.) Therefore, instead of using a static function, we can build the list on a per RubySystem basis. The cachememory and directorymemory objects should be able to get a pointer to their associated RubySystem using the Parent.any directive in their .py file. See the following line in sim/System.py for an example 'physmem = Param.PhysicalMemory(Parent.any, physical memory)'. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, March 08, 2011 3:22 AM To: Beckmann, Brad Cc: m5-dev@m5sim.org Subject: RE: Functional Interface in Ruby It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay On Mon, 7 Mar 2011, Beckmann, Brad wrote: Hi Nilay, Please excuse the slow response. I've been meaning to reply to this email for a few days. Absolutely, we will need to maintain some sort of list of all cachememory and directorymemory objects to make the functional access support work. However, I'm not sure if we'll need to modify the protocol python files. Instead, could we create a list of these objects through their c++ constructors similar to how the SimObject list is created? Also, I know the line between the RubyPort and Sequencer is quite blurry, but is there a particular reason to push the functional access support into the Sequencer? It seems that the RubyPort would be a more natural location. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Friday, March 04, 2011 9:49 AM To: Beckmann, Brad Cc: m5-dev@m5sim.org Subject: Functional Interface in Ruby I have been thinking about how to make Ruby support functional accesses. It seems some where we will have to add support so that either RubyPort or Sequencer can view all other caches. I am currently leaning towards adding it to the sequencer. I think this can be done by editing protocol files in configs/ruby. And then RubyPort can pass on functional accesses to the Sequencer, which will look up all the caches and take the correct action. I think this can be made to work. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
Hi Nilay, It looks like my email filter of the m5-dev list cause me to basically send you the same suggestion that Steve sent you. Sorry for the confusion, but it is good to know that Steve and I at least are considering the same problem. From now on, let's drop our individual email addresses and just direct our responses to m5-dev. Brad From: Steve Reinhardt [mailto:ste...@gmail.com] Sent: Tuesday, March 08, 2011 7:18 AM To: M5 Developer List Cc: Nilay Vaish; Beckmann, Brad Subject: Re: [m5-dev] Functional Interface in Ruby Forgot to mention that this is how we handle registering all the thread contexts within a system... you can look at that code (in the CPU models and in System) for an example. On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt ste...@gmail.commailto:ste...@gmail.com wrote: Sorry I missed this thread... I just read Nilay's response about python issues and he pointed me over here. One thing we should think about is that we really only want the caches within a single system to be flushed at once... I know that it's unlikely that anyone will want to model two systems with detailed memory models at once, and I vaguely recall there were other issues with Ruby not really supporting multiple instances of itself, but I don't want to see us make things less modular than they already are. The m5 idiom for doing this is: - add a parameter to each cache/controller/whatever we want to track like this: system = Param.System(Parent.any, system object) - add a method to the System object like registerCache(Cache *c) that adds c to the system object's list of caches - Have each cache constructor call p-system-registerCache(this) to register itself Would something like this work for what you're trying to do? Steve On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish ni...@cs.wisc.edumailto:ni...@cs.wisc.edu wrote: It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay On Mon, 7 Mar 2011, Beckmann, Brad wrote: Hi Nilay, Please excuse the slow response. I've been meaning to reply to this email for a few days. Absolutely, we will need to maintain some sort of list of all cachememory and directorymemory objects to make the functional access support work. However, I'm not sure if we'll need to modify the protocol python files. Instead, could we create a list of these objects through their c++ constructors similar to how the SimObject list is created? Also, I know the line between the RubyPort and Sequencer is quite blurry, but is there a particular reason to push the functional access support into the Sequencer? It seems that the RubyPort would be a more natural location. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edumailto:ni...@cs.wisc.edu] Sent: Friday, March 04, 2011 9:49 AM To: Beckmann, Brad Cc: m5-dev@m5sim.orgmailto:m5-dev@m5sim.org Subject: Functional Interface in Ruby I have been thinking about how to make Ruby support functional accesses. It seems some where we will have to add support so that either RubyPort or Sequencer can view all other caches. I am currently leaning towards adding it to the sequencer. I think this can be done by editing protocol files in configs/ruby. And then RubyPort can pass on functional accesses to the Sequencer, which will look up all the caches and take the correct action. I think this can be made to work. Nilay ___ m5-dev mailing list m5-dev@m5sim.orgmailto: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] Review Request: MOESI_hammer: adding cache flushing
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/552/#review936 --- Hi Somayeh, I have several comments and questions that pertain to both the design and the coding style. Please don't be discouraged by the number of my comments. Most people's first review tend to look like this. In general, I think you changes to the protocol are more complicated than they need to be. The flush request should be a blocking request, just like other requests. Returning to a base state when the flush request is still outstanding will cause you bunch of unnecessary pain, and you'll likely never get that to completely work. Let me know if you have any questions and once you address my comments please submit the next version of your patch for review. I'd rather provide you feedback sooner than have you work several weeks in isolation. src/cpu/testers/rubytest/Check.hh http://reviews.m5sim.org/r/552/#comment1270 Don't add comments such as this. Mercurial provides us this information and adding explicit comments like this is redundant and will only clutter the code. I see you did this in several places. I didn't mark each one of them, but please correct them all. Thanks! src/cpu/testers/rubytest/Check.cc http://reviews.m5sim.org/r/552/#comment1271 Minor comment: Please add a space between '==' and '0'. src/cpu/testers/rubytest/Check.cc http://reviews.m5sim.org/r/552/#comment1281 Why are you setting the data pointer to a non-null value? It seesm that the flush request should be dataless. src/mem/packet.cc http://reviews.m5sim.org/r/552/#comment1272 Don't exceed 80 characters per line. src/mem/physical.cc http://reviews.m5sim.org/r/552/#comment1282 This condition and the similar condition below are awkward and I don't think they are necessary. In general, I don't think this patch should impact physicalmemory at all. Instead, inside the function RubyPort::M5Port::hitCallback() cache flush requests should set the local variable accessPhysMem to false, similar to how failed SC request behave. src/mem/protocol/MOESI_hammer-cache.sm http://reviews.m5sim.org/r/552/#comment1288 If you implement the flush mechanism in a more blocking fashion, I don't think you need as many events that just pertain to flushing. In particular, having to start a flush over is something you want to avoid at all costs. If implemented correctly, the initial flush request should eventually succeed. In general, nack and retry mechanisms are particularly tricky to test in ruby because the random tester tends to find the pathelogical deadlock case. src/mem/protocol/MOESI_hammer-cache.sm http://reviews.m5sim.org/r/552/#comment1283 paranthesis alignment src/mem/protocol/MOESI_hammer-cache.sm http://reviews.m5sim.org/r/552/#comment1289 Is there a reason why you need this action and the vt_ action for writing the tbe versus using the pre-existing actions? src/mem/protocol/MOESI_hammer-cache.sm http://reviews.m5sim.org/r/552/#comment1285 Minor comment: No need to modify this line. src/mem/protocol/MOESI_hammer-cache.sm http://reviews.m5sim.org/r/552/#comment1284 Why issue a db_issueBlock? Since the hammer protocol uses exclusive L1/L2 caches managed by a single controller, don't you know that this is the only cached copy of the block? Can't you just directly issue the PUTX request? src/mem/protocol/MOESI_hammer-cache.sm http://reviews.m5sim.org/r/552/#comment1286 Do not transition to a base state here or in the following three transitions. Instead, you should either remain in the same transient state or transition to another transient state. In general, if you've issued a request to the directory, you what to remain in a transient state until your entire request has been satisfied. Going back to a base state and reissuing the flush or invalidate request creates a bunch of races and puts open ended requests in the system that will be nearly impossible to track down. Understand how the current protocol works when receives forwarded requests in transient states and implement a similar behavior for flushes. src/mem/protocol/MOESI_hammer-dir.sm http://reviews.m5sim.org/r/552/#comment1287 If you implement the flush mechanism in a more blocking fashion, I don't believe you should have races between BLOCK and UnblockM. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/552/#comment1280 indents should be four spaces wide. src/mem/ruby/system/Sequencer.hh http://reviews.m5sim.org/r/552/#comment1279 The spacing seems slightly off here and the next function declaration. The parameters should line up to the right of the open parenthesis. src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/552/#comment1273 Again, do not
Re: [m5-dev] Functional Interface in Ruby
When does the following error occurs? Is it that an object is being accessed while it is being created? File /afs/cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m5/SimObject.py, line 834, in getCCObject raise RuntimeError, %s: Cycle found in configuration hierarchy. \ RuntimeError: system.l1_cntrl0.L1DcacheMemory: Cycle found in configuration hierarchy. -- Nilay On Tue, 8 Mar 2011, Steve Reinhardt wrote: Forgot to mention that this is how we handle registering all the thread contexts within a system... you can look at that code (in the CPU models and in System) for an example. On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt ste...@gmail.com wrote: Sorry I missed this thread... I just read Nilay's response about python issues and he pointed me over here. One thing we should think about is that we really only want the caches within a single system to be flushed at once... I know that it's unlikely that anyone will want to model two systems with detailed memory models at once, and I vaguely recall there were other issues with Ruby not really supporting multiple instances of itself, but I don't want to see us make things less modular than they already are. The m5 idiom for doing this is: - add a parameter to each cache/controller/whatever we want to track like this: system = Param.System(Parent.any, system object) - add a method to the System object like registerCache(Cache *c) that adds c to the system object's list of caches - Have each cache constructor call p-system-registerCache(this) to register itself Would something like this work for what you're trying to do? Steve On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish ni...@cs.wisc.edu wrote: It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
It probably means that two objects have pointers to each other as parameters (or more generally there's a cycle). See step 3 here: http://m5sim.org/wiki/index.php/SimObject_Initialization On Tue, Mar 8, 2011 at 4:27 PM, Nilay Vaish ni...@cs.wisc.edu wrote: When does the following error occurs? Is it that an object is being accessed while it is being created? File /afs/ cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m5/SimObject.py, line 834, in getCCObject raise RuntimeError, %s: Cycle found in configuration hierarchy. \ RuntimeError: system.l1_cntrl0.L1DcacheMemory: Cycle found in configuration hierarchy. -- Nilay On Tue, 8 Mar 2011, Steve Reinhardt wrote: Forgot to mention that this is how we handle registering all the thread contexts within a system... you can look at that code (in the CPU models and in System) for an example. On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt ste...@gmail.com wrote: Sorry I missed this thread... I just read Nilay's response about python issues and he pointed me over here. One thing we should think about is that we really only want the caches within a single system to be flushed at once... I know that it's unlikely that anyone will want to model two systems with detailed memory models at once, and I vaguely recall there were other issues with Ruby not really supporting multiple instances of itself, but I don't want to see us make things less modular than they already are. The m5 idiom for doing this is: - add a parameter to each cache/controller/whatever we want to track like this: system = Param.System(Parent.any, system object) - add a method to the System object like registerCache(Cache *c) that adds c to the system object's list of caches - Have each cache constructor call p-system-registerCache(this) to register itself Would something like this work for what you're trying to do? Steve On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish ni...@cs.wisc.edu wrote: It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- 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] Review Request: MOESI_hammer: adding cache flushing
On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/protocol/MOESI_hammer-cache.sm, line 1096 http://reviews.m5sim.org/r/552/diff/1/?file=10718#file10718line1096 Is there a reason why you need this action and the vt_ action for writing the tbe versus using the pre-existing actions? In this case, the TBE entry may not have the data. The added uf_ action stores data in TBE. The reason I added this action is that I do not want to allocate the cache line in the cache when I want to flush it, so I keep/update it in TBE during the flush. This action is similar to u_writeDataToCache, but it only updates TBE entry. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/cpu/testers/rubytest/Check.hh, line 64 http://reviews.m5sim.org/r/552/diff/1/?file=10713#file10713line64 Don't add comments such as this. Mercurial provides us this information and adding explicit comments like this is redundant and will only clutter the code. I see you did this in several places. I didn't mark each one of them, but please correct them all. Thanks! I applied it in the new version. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/cpu/testers/rubytest/Check.cc, line 65 http://reviews.m5sim.org/r/552/diff/1/?file=10714#file10714line65 Minor comment: Please add a space between '==' and '0'. I applied it in the new version. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/cpu/testers/rubytest/Check.cc, line 218 http://reviews.m5sim.org/r/552/diff/1/?file=10714#file10714line218 Why are you setting the data pointer to a non-null value? It seesm that the flush request should be dataless. In this version, to make testing easier, flush requests return data, and are randomly used instead of loads. I will fix it in future patches. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/packet.cc, line 153 http://reviews.m5sim.org/r/552/diff/1/?file=10716#file10716line153 Don't exceed 80 characters per line. applied! On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/physical.cc, line 325 http://reviews.m5sim.org/r/552/diff/1/?file=10717#file10717line325 This condition and the similar condition below are awkward and I don't think they are necessary. In general, I don't think this patch should impact physicalmemory at all. Instead, inside the function RubyPort::M5Port::hitCallback() cache flush requests should set the local variable accessPhysMem to false, similar to how failed SC request behave. applied! On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/protocol/MOESI_hammer-cache.sm, line 133 http://reviews.m5sim.org/r/552/diff/1/?file=10718#file10718line133 If you implement the flush mechanism in a more blocking fashion, I don't think you need as many events that just pertain to flushing. In particular, having to start a flush over is something you want to avoid at all costs. If implemented correctly, the initial flush request should eventually succeed. In general, nack and retry mechanisms are particularly tricky to test in ruby because the random tester tends to find the pathelogical deadlock case. This event and related states are removed in the new implementation. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/protocol/MOESI_hammer-cache.sm, line 1518 http://reviews.m5sim.org/r/552/diff/1/?file=10718#file10718line1518 Why issue a db_issueBlock? Since the hammer protocol uses exclusive L1/L2 caches managed by a single controller, don't you know that this is the only cached copy of the block? Can't you just directly issue the PUTX request? It has been removed in the new implementation. However, even if the cache has the line exclusively, it should block the directory before directly issuing PUTX. In this way, the directory stalls new requests for this line until the flush is done. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/protocol/MOESI_hammer-dir.sm, line 1838 http://reviews.m5sim.org/r/552/diff/1/?file=10719#file10719line1838 If you implement the flush mechanism in a more blocking fashion, I don't believe you should have races between BLOCK and UnblockM. I am not sure if I need this any more in the new implementation. I will check it. On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/ruby/system/RubyPort.cc, line 248 http://reviews.m5sim.org/r/552/diff/1/?file=10726#file10726line248 indents should be four spaces wide. done! On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/ruby/system/Sequencer.hh, line 106 http://reviews.m5sim.org/r/552/diff/1/?file=10727#file10727line106 The spacing seems slightly off here and the next function declaration. The parameters should line up to the right of the open parenthesis. done! On 2011-03-08 11:53:38, Brad Beckmann wrote: src/mem/ruby/system/Sequencer.cc, line 259
[m5-dev] Review Request: MOESI_hammer: cache flush support: Fix the deadlock issue, and Clean up the changed files
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/553/ --- Review request for Default and Brad Beckmann. Summary --- MOESI_hammer: cache flush support: Fix the deadlock issue, and clean up the changed files In this version, I have redesigned the cache flushing mechanism for the case that the line is already in exclusive state in the cache. I think this implementation solves the reported deadlock issue. I have also applied Brad's comments. Diffs - src/cpu/testers/rubytest/Check.hh baf4b5f6782e src/cpu/testers/rubytest/Check.cc baf4b5f6782e src/mem/packet.hh baf4b5f6782e src/mem/packet.cc baf4b5f6782e src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e src/mem/ruby/system/DMASequencer.cc baf4b5f6782e src/mem/ruby/system/RubyPort.cc baf4b5f6782e src/mem/ruby/system/Sequencer.hh baf4b5f6782e src/mem/ruby/system/Sequencer.cc baf4b5f6782e Diff: http://reviews.m5sim.org/r/553/diff Testing --- This implementation passes 1,000,000 ruby test cases, and is under test for 10,000,000 cases (with random_seed activated). Thanks, Somayeh ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: MOESI_hammer: cache flush support: Fix the deadlock issue, and Clean up the changed files
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/554/ --- Review request for Default and Brad Beckmann. Summary --- MOESI_hammer: cache flush support: Fix the deadlock issue, and clean up the changed files In this version, I have redesigned the cache flushing mechanism for the case that the line is already in exclusive state in the cache. I think this implementation solves the reported deadlock issue. I have also applied Brad's comments. Diffs - src/cpu/testers/rubytest/Check.hh baf4b5f6782e src/cpu/testers/rubytest/Check.cc baf4b5f6782e src/mem/packet.hh baf4b5f6782e src/mem/packet.cc baf4b5f6782e src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e src/mem/ruby/system/DMASequencer.cc baf4b5f6782e src/mem/ruby/system/RubyPort.cc baf4b5f6782e src/mem/ruby/system/Sequencer.hh baf4b5f6782e src/mem/ruby/system/Sequencer.cc baf4b5f6782e Diff: http://reviews.m5sim.org/r/554/diff Testing --- This implementation passes 1,000,000 ruby test cases, and is under test for 10,000,000 cases (with random_seed activated). Thanks, Somayeh ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: MOESI_hammer: cache flush support: Fix the deadlock issue, and Clean up the changed files
Somayeh, there is an update option available in postreview. I think it is -u request number. You can use that to post update already created review requests. -- Nilay On Wed, 9 Mar 2011, Somayeh Sardashti wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/554/ --- Review request for Default and Brad Beckmann. Summary --- MOESI_hammer: cache flush support: Fix the deadlock issue, and clean up the changed files In this version, I have redesigned the cache flushing mechanism for the case that the line is already in exclusive state in the cache. I think this implementation solves the reported deadlock issue. I have also applied Brad's comments. Diffs - src/cpu/testers/rubytest/Check.hh baf4b5f6782e src/cpu/testers/rubytest/Check.cc baf4b5f6782e src/mem/packet.hh baf4b5f6782e src/mem/packet.cc baf4b5f6782e src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e src/mem/ruby/system/DMASequencer.cc baf4b5f6782e src/mem/ruby/system/RubyPort.cc baf4b5f6782e src/mem/ruby/system/Sequencer.hh baf4b5f6782e src/mem/ruby/system/Sequencer.cc baf4b5f6782e Diff: http://reviews.m5sim.org/r/554/diff Testing --- This implementation passes 1,000,000 ruby test cases, and is under test for 10,000,000 cases (with random_seed activated). Thanks, Somayeh ___ 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
