[m5-dev] Cron m5t...@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-ruby passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. = Statistics differences == Statistics differences =* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-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/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 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/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-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/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_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/60.rubytest/alpha/linux/rubytest-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_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_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_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-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/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual 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-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_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. *
Re: [m5-dev] Review Request: scons: show sources and targets when building.
On Tue, Jan 4, 2011 at 10:09 PM, nathan binkert n...@binkert.org wrote: Neat idea, but you need to check sys.stdout.isatty() and conditionally add the color. Then you're going to want a way to override that if you're piping through less :) Seems like we could add a --color option to the SCons command line. It actually crossed my mind earlier today to use colorization to distinguish the common prefix part of the source path from the source-specific part, as a way of eliminating the ambiguity of how to form the target. The isatty check would take care of the less problem, though... Actually less -r allows you to take the control characters, so the --color would override the isatty() == false and output the control codes anyway. Ah, got it, I misunderstood your comment. As a thought, TRANSFORM should probably take the action abbreviation (e.g. CC) as a parameter if you're going to do the colorization. I don't follow... do you think the filenames should be colorized differently depending on the command? Note that the TRANSFORM* functions don't get called directly by the user so you can't add params anyway (unless there's a mechanism I'm unaware of). This is all overkill, but is a nice feature imho. True enough... Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
As a thought, TRANSFORM should probably take the action abbreviation (e.g. CC) as a parameter if you're going to do the colorization. I don't follow... do you think the filenames should be colorized differently depending on the command? Note that the TRANSFORM* functions don't get called directly by the user so you can't add params anyway (unless there's a mechanism I'm unaware of). No, I think all of the colorization should be in a single function. It's definitely a mechanism to allow transform to take an argument. So you change this: main['CCCOMSTR']= ' [ CC] $TRANSFORM' to this: main['CCCOMSTR']= ' $TRANSFORM(CC)' I had initially implemented the STRIP stuff like that and I don't remember exactly how it worked, but my recollection is that TRANSFORM(CC) was called, expected to return a callable, then that callable was called as TRANSFORM is now (I just created a class). All that said, I think that the RHS of this thing is also allowed to be a function and we don't have to use the SCons string substitution. You'd want to do the same callable object thing. Make sense? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
1. Below is a snip of a protocol trace that I recently used. I think it is important for us maintain that there is no DPRINTF information prepended to each line. The initial motivation for the protocol trace, was that tracing protocol transitions using standard debug print was too verbose. These traces can be 100’MB if not GBs in size, so reducing the information printed to each line is important. Nilay, could you send a snip of the trace with the patch applied? 2233850 3L1CacheLoad IIS [0x409ec0, line 0x409ec0] 2233850 3L1Cache L2_Replacement MMI [0x40cfc0, line 0x40cfc0] 2233866 3L1Cache Writeback_Ack MII [0x10bd40, line 0x10bd40] 2233866 3L1Cache Writeback_Ack MII [0x40cfc0, line 0x40cfc0] 2234458 3SeqDone [0x4033c3, line 0x4033c0] 3380 cycles 2234458 3L1Cache Exclusive_Data IMMM_W [0x4033c0, line 0x4033c0] 0Directory-0 2234458 3Seq Begin [0x40f883, line 0x40f880] ST 2234459 3L1Cache All_acks_no_sharers MM_WMM [0x4033c0, line 0x4033c0] 2234508 3L1Cache Exclusive_Data ISM_W[0x409ec0, line 0x409ec0] 0Directory-0 2234509 3L1Cache All_acks_no_sharersM_WM [0x409ec0, line 0x409ec0] 2234510 3L1CacheL1_to_L2 [0x4033c0, line 0x4033c0] 2234510 3L1CacheLoad IIS [0x407ec0, line 0x407ec0] 2234510 3L1Cache L2_Replacement MMI [0x40b4c0, line 0x40b4c0] 2234510 3L1CacheL1_to_L2 MM [0x409ec0, line 0x409ec0] 2234510 3L1CacheLoad IIS [0x100c40, line 0x100c40] 2234510 3L1Cache L2_Replacement MMMI [0x4033c0, line 0x4033c0] 2. Just for my own knowledge… Nate, you mentioned that handling the SIGABRT signal is the right way to make this feature work for all of M5. Why is that? Is it just the preference not to use macros that overwrite the meaning of assert, or is it something more fundamental? Thanks, Brad From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, January 04, 2011 7:24 PM To: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert Cc: Nilay Vaish; Default; Beckmann, Brad Subject: Re: Review Request: ruby: get rid of ruby's Debug.hh This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/367/ On January 4th, 2011, 4:31 p.m., Brad Beckmann wrote: Hi Nate, I have a couple questions: 1. Have you looked at the protocol trace output after your change? Does it look exactly like it did before? It seems that the output should be the same based on my brief inspection of your patch, but I would like to be sure about that. It may not be obvious, but there is a specific rational behind the format of the protocol trace and I want to make sure that stays the same. 2. With your patch applied, what happens if one hits an assert when running interactively? Previously, the process would abort allowing one to attach gdb and examine what is going on. I liked that feature and it would be great if we could maintain it. Could we port that feature to all of M5? On January 4th, 2011, 6:05 p.m., Nathan Binkert wrote: 1) I have not, because I don't know how, but I tried hard to make it exactly the same. Can you help me out? It won't look identical because DPRINTF prepends some stuff (curTick and object name) 2) we don't have a mechanism to have the process stall until GDB is attached, but given that this worked in Ruby only, I'd agree that this should be something that we do globally in M5. The right way to do this would be to handle SIGABRT and stall in the abort handler (I think that should work). Can we work on this patch and do that as a separate one? Brad, do you have some protocol trace with you? I have seen the trace that gets generated with the current trace facility using Ruby trace flag. It prints all the events for all the cache controllers and network routers. If you prefer, I can send you an example trace. Or you can generate one by running m5.opt with trace file and trace flag options supplied. ./build/ALPHA_SE_MESI_CMP_directory/m5.opt --trace-file=MESI.trace --trace-flags=Ruby ./configs/example/ruby_random_test.py -l 1000 - Nilay On January 4th, 2011, 3:02 p.m., Nathan Binkert wrote: Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. By Nathan Binkert. Updated 2011-01-04 15:02:38 Description ruby: get rid of ruby's Debug.hh Get rid of the Debug class Get rid of ASSERT and use assert Use DPRINTF for ProtocolTrace Testing This compiles and passes all of the quick regressions, but it would be nice for a Ruby developer to take a look and see if I got rid of any useful functionality. Diffs * configs/ruby/Ruby.py (7338bc628489) * src/mem/SConscript
Re: [m5-dev] Review Request: O3: Fixes the way prefetches are handled inside the iew unit. This patch
On 2010-12-21 17:29:39, Steve Reinhardt wrote: src/arch/arm/tlb.cc, line 562 http://reviews.m5sim.org/r/342/diff/1/?file=5459#file5459line562 It seems to me like we ought to have a generic check in the CPU models that prevents prefetches to uncacheable locations rather than burying this in the TLB and requiring every ISA to make this check. (Which leads to the question of how/whether this is handled in other ISAs...) Prefetches aren't implemented in Alpha so this hasn't been an issue. I don't know that I agree it should be in a generic place because I don't know that uncachable is equivalent to non-prefetchable. For example, an memory could be marked cacheable but not prefetchable in sparc if memory serves (same is probably true for some ASI accesses). I think the TLB really needs to make the decision because it's got all of the relevant information. - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/342/#review559 --- On 2010-12-06 16:12:26, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/342/ --- (Updated 2010-12-06 16:12:26) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- O3: Fixes the way prefetches are handled inside the iew unit. This patch prevents the prefetch being added to the instCommit queue twice. Diffs - src/arch/arm/faults.hh 2b5fbdcbfb5d src/arch/arm/tlb.cc 2b5fbdcbfb5d src/cpu/o3/iew_impl.hh 2b5fbdcbfb5d Diff: http://reviews.m5sim.org/r/342/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Brad, This how protocol trace would look like. I actually did not some such thing exists. I was currently relying on DPRINTF statements for checking the events that occurred. This is certainly easier to read and much more compact. 1395: system.l1_cntrl3:1395 3L1Cache L1_Replacement IMIM [0x15c0, line 0x15c0] 1395: system.l1_cntrl2:1395 2L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2:1395 2L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2:1395 2L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1396: system.l1_cntrl1:1396 1L1Cache L1_Replacement IMIM [0x2ac0, line 0x2ac0] 1397: system.ruby.cpu_ruby_ports2:1397 2Seq Done [0x3ae8, line 0x3ac0] 1386 cycles 1397: system.l1_cntrl2:1397 2L1Cache Data_all_Acks IMM [0x3ac0, line 0x3ac0] 1397: system.l1_cntrl3:1397 3L1Cache L1_Replacement IMIM [0x15c0, line 0x15c0] 1397: system.l2_cntrl0:1397 0L2CacheL2_Replacement_clean MT_MBMT_MB [0x3ac0, line 0x3ac0] 1400: system.l2_cntrl0:1400 0L2Cache L1_GETX MT_MBMT_MB [0x400, line 0x400] 1401: system.l2_cntrl0:1401 0L2CacheL2_Replacement_clean MT_MBMT_MB [0x3ac0, line 0x3ac0] 1402: system.l1_cntrl0:1402 0L1Cache L1_Replacement IMIM [0x4dc0, line 0x4dc0] 1402: system.l1_cntrl2:1402 2L1Cache L1_Replacement IMIM [0xdc0, line 0xdc0] 1402: system.l1_cntrl2:1402 2L1Cache L1_Replacement IMIM [0xdc0, line 0xdc0] On Wed, January 5, 2011 10:26 am, Beckmann, Brad wrote: 1. Below is a snip of a protocol trace that I recently used. I think it is important for us maintain that there is no DPRINTF information prepended to each line. The initial motivation for the protocol trace, was that tracing protocol transitions using standard debug print was too verbose. These traces can be 100âMB if not GBs in size, so reducing the information printed to each line is important. Nilay, could you send a snip of the trace with the patch applied? 2233850 3L1CacheLoad IIS [0x409ec0, line 0x409ec0] 2233850 3L1Cache L2_Replacement MMI [0x40cfc0, line 0x40cfc0] 2233866 3L1Cache Writeback_Ack MII [0x10bd40, line 0x10bd40] 2233866 3L1Cache Writeback_Ack MII [0x40cfc0, line 0x40cfc0] 2234458 3SeqDone [0x4033c3, line 0x4033c0] 3380 cycles 2234458 3L1Cache Exclusive_Data IMMM_W [0x4033c0, line 0x4033c0] 0Directory-0 2234458 3Seq Begin [0x40f883, line 0x40f880] ST 2234459 3L1Cache All_acks_no_sharers MM_WMM [0x4033c0, line 0x4033c0] 2234508 3L1Cache Exclusive_Data ISM_W[0x409ec0, line 0x409ec0] 0Directory-0 2234509 3L1Cache All_acks_no_sharersM_WM [0x409ec0, line 0x409ec0] 2234510 3L1CacheL1_to_L2 [0x4033c0, line 0x4033c0] 2234510 3L1CacheLoad IIS [0x407ec0, line 0x407ec0] 2234510 3L1Cache L2_Replacement MMI [0x40b4c0, line 0x40b4c0] 2234510 3L1CacheL1_to_L2 MM [0x409ec0, line 0x409ec0] 2234510 3L1CacheLoad IIS [0x100c40, line 0x100c40] 2234510 3L1Cache L2_Replacement MMMI [0x4033c0, line 0x4033c0] 2. Just for my own knowledge⦠Nate, you mentioned that handling the SIGABRT signal is the right way to make this feature work for all of M5. Why is that? Is it just the preference not to use macros that overwrite the meaning of assert, or is it something more fundamental? Thanks, Brad From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, January 04, 2011 7:24 PM To: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert Cc: Nilay Vaish; Default; Beckmann, Brad Subject: Re: Review Request: ruby: get rid of ruby's Debug.hh This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/367/ On January 4th, 2011, 4:31 p.m., Brad Beckmann wrote: Hi Nate, I have a couple questions: 1. Have you looked at the protocol trace output after your change? Does it look exactly like it did before? It seems that the output should be the same based on my brief inspection of your patch, but I would like to be sure about that. It may not be obvious, but there is a specific rational behind the format of the protocol trace and I want to make sure that stays the same. 2. With your patch applied, what happens if one hits an assert when running interactively? Previously, the process would abort allowing one to attach gdb and examine what is going on. I liked
Re: [m5-dev] curTick global variable
On Tue, Jan 4, 2011 at 5:56 PM, nathan binkert n...@binkert.org wrote: I want to keep this a purely syntactic change, because I think the semantic changes are going to require some discussion. For example, my current next-step patch replaces mainEventQueue with an array of queues (so there is no single main event queue any more), and uses TLS to implement per-thread curTick values rather than embedding them in the queues, so it doesn't follow the path you're proposing. If you want to discuss this further please start a new email thread. The good news is that once this patch gets committed then all these options can be explored with fairly local changes. Interesting. If you were going to do this, why do you need accessors at all? It's a flexibility/fear-of-commitment thing... initially I wasn't positive which way I would go, and once I decided that curTick-as-EventQueue/Manager-field wasn't going to work well (too many places where it's pretty awkward to find the object pointer), I figured it would still be useful in case we need to use pthread_setspecific/getspecific on some platforms (OS X? OpenBSD? Cygwin?). I also kind of like how it indicates that curTick is not a normal variable... implicitly declaring it as part of TLS in one file without any indication at each reference that it's different seems potentially confusing. This seems to mean that I shouldn't have created the whole EventManager thing and had schedule be a per-object thing. Why do you say that? Because you could put the EventQueue pointer in TLS too and not do the object-based lookup? I think it would be useful to check that the EventManager queue pointer and the TLS queue pointer are the same. TLS scares me, but maybe that's unnecessarily. :) Why? How were you planning on having thread 1 schedule an event on thread 2's eventq? Were you going to use some sort of FIFO between threads? One per eventq with a lock only on the producer side, or one lock-free per pair of threads? (I assume the former. I have code somewhere for the latter that I wrote a long time ago.) Further assuming that the FIFO is a yes, how were you going to check it? Polling it periodically? Seems that this could all be rolled into the whole async wrapper around the event queue. I haven't gotten that far yet, but yes, something like the locked external queue with async polling was what I was thinking of so far. I've been approaching it more top-down: what should simulate() look like, how do we do initialization, etc. Anyway, I've thought about this a lot. Happy to do a phone call if you want. Sure, I've got some time today late morning early afternoon if you're free. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Looks like we should just remove the first, second, and third columns that are spit out since they're covered almost exactly by the implicit columns added by DPRINTF. Right? Nate This how protocol trace would look like. I actually did not some such thing exists. I was currently relying on DPRINTF statements for checking the events that occurred. This is certainly easier to read and much more compact. 1395: system.l1_cntrl3: 1395 3 L1Cache L1_Replacement IMIM [0x15c0, line 0x15c0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1396: system.l1_cntrl1: 1396 1 L1Cache L1_Replacement IMIM [0x2ac0, line 0x2ac0] 1397: system.ruby.cpu_ruby_ports2: 1397 2 Seq Done [0x3ae8, line 0x3ac0] 1386 cycles 1397: system.l1_cntrl2: 1397 2 L1Cache Data_all_Acks IMM [0x3ac0, line 0x3ac0] 1397: system.l1_cntrl3: 1397 3 L1Cache L1_Replacement IMIM [0x15c0, line 0x15c0] 1397: system.l2_cntrl0: 1397 0 L2CacheL2_Replacement_clean MT_MBMT_MB [0x3ac0, line 0x3ac0] 1400: system.l2_cntrl0: 1400 0 L2Cache L1_GETX MT_MBMT_MB [0x400, line 0x400] 1401: system.l2_cntrl0: 1401 0 L2CacheL2_Replacement_clean MT_MBMT_MB [0x3ac0, line 0x3ac0] 1402: system.l1_cntrl0: 1402 0 L1Cache L1_Replacement IMIM [0x4dc0, line 0x4dc0] 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement IMIM [0xdc0, line 0xdc0] 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement IMIM [0xdc0, line 0xdc0] On Wed, January 5, 2011 10:26 am, Beckmann, Brad wrote: 1. Below is a snip of a protocol trace that I recently used. I think it is important for us maintain that there is no DPRINTF information prepended to each line. The initial motivation for the protocol trace, was that tracing protocol transitions using standard debug print was too verbose. These traces can be 100’MB if not GBs in size, so reducing the information printed to each line is important. Nilay, could you send a snip of the trace with the patch applied? 2233850 3 L1Cache Load IIS [0x409ec0, line 0x409ec0] 2233850 3 L1Cache L2_Replacement MMI [0x40cfc0, line 0x40cfc0] 2233866 3 L1Cache Writeback_Ack MII [0x10bd40, line 0x10bd40] 2233866 3 L1Cache Writeback_Ack MII [0x40cfc0, line 0x40cfc0] 2234458 3 Seq Done [0x4033c3, line 0x4033c0] 3380 cycles 2234458 3 L1Cache Exclusive_Data IMMM_W [0x4033c0, line 0x4033c0] 0Directory-0 2234458 3 Seq Begin [0x40f883, line 0x40f880] ST 2234459 3 L1Cache All_acks_no_sharers MM_WMM [0x4033c0, line 0x4033c0] 2234508 3 L1Cache Exclusive_Data ISM_W [0x409ec0, line 0x409ec0] 0Directory-0 2234509 3 L1Cache All_acks_no_sharers M_WM [0x409ec0, line 0x409ec0] 2234510 3 L1Cache L1_to_L2 [0x4033c0, line 0x4033c0] 2234510 3 L1Cache Load IIS [0x407ec0, line 0x407ec0] 2234510 3 L1Cache L2_Replacement MMI [0x40b4c0, line 0x40b4c0] 2234510 3 L1Cache L1_to_L2 MM [0x409ec0, line 0x409ec0] 2234510 3 L1Cache Load IIS [0x100c40, line 0x100c40] 2234510 3 L1Cache L2_Replacement MMMI [0x4033c0, line 0x4033c0] 2. Just for my own knowledge… Nate, you mentioned that handling the SIGABRT signal is the right way to make this feature work for all of M5. Why is that? Is it just the preference not to use macros that overwrite the meaning of assert, or is it something more fundamental? Thanks, Brad From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, January 04, 2011 7:24 PM To: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert Cc: Nilay Vaish; Default; Beckmann, Brad Subject: Re: Review Request: ruby: get rid of ruby's Debug.hh This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/367/ On January 4th, 2011, 4:31 p.m., Brad Beckmann wrote: Hi Nate, I have a couple questions: 1. Have you looked at the protocol trace output after your change? Does it look exactly like it did before? It seems that the output should be the same based on my brief inspection of your patch, but I would like to be sure about that. It may not be obvious, but there is a specific rational behind the format of the protocol trace and I want to make sure that stays the same. 2. With your patch applied, what happens if one hits an
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
1. Below is a snip of a protocol trace that I recently used. I think it is important for us maintain that there is no DPRINTF information prepended to each line. The initial motivation for the protocol trace, was that tracing protocol transitions using standard debug print was too verbose. These traces can be 100’MB if not GBs in size, so reducing the information printed to each line is important. Nilay, could you send a snip of the trace with the patch applied? Re DPRINTF, see my response to Nilay, but in short, we should just remove some of the columns that you guys have and I think it will be a wash. If that's not sufficient, we can use DPRINTFN. One thing to do then would be to add support for writing these to a gzipped file (that may already just work), no? 2. Just for my own knowledge… Nate, you mentioned that handling the SIGABRT signal is the right way to make this feature work for all of M5. Why is that? Is it just the preference not to use macros that overwrite the meaning of assert, or is it something more fundamental? Not fundamental. Mostly because we don't want multiple meanings of assert. It seems that if we could get this to work properly that it would be easiest as well. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Is it possible to fix the width of the information prepended by DPRINTF? I would be great if we could maintain the current fixed width format. Brad -Original Message- From: bink...@gmail.com [mailto:bink...@gmail.com] On Behalf Of nathan binkert Sent: Wednesday, January 05, 2011 10:36 AM To: M5 Developer List Cc: Beckmann, Brad Subject: Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh Looks like we should just remove the first, second, and third columns that are spit out since they're covered almost exactly by the implicit columns added by DPRINTF. Right? Nate This how protocol trace would look like. I actually did not some such thing exists. I was currently relying on DPRINTF statements for checking the events that occurred. This is certainly easier to read and much more compact. 1395: system.l1_cntrl3: 1395 3 L1Cache L1_Replacement IMIM [0x15c0, line 0x15c0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IMIM [0x3ac0, line 0x3ac0] 1396: system.l1_cntrl1: 1396 1 L1Cache L1_Replacement IMIM [0x2ac0, line 0x2ac0] 1397: system.ruby.cpu_ruby_ports2: 1397 2 Seq Done [0x3ae8, line 0x3ac0] 1386 cycles 1397: system.l1_cntrl2: 1397 2 L1Cache Data_all_Acks IMM [0x3ac0, line 0x3ac0] 1397: system.l1_cntrl3: 1397 3 L1Cache L1_Replacement IMIM [0x15c0, line 0x15c0] 1397: system.l2_cntrl0: 1397 0 L2CacheL2_Replacement_clean MT_MBMT_MB [0x3ac0, line 0x3ac0] 1400: system.l2_cntrl0: 1400 0 L2Cache L1_GETX MT_MBMT_MB [0x400, line 0x400] 1401: system.l2_cntrl0: 1401 0 L2CacheL2_Replacement_clean MT_MBMT_MB [0x3ac0, line 0x3ac0] 1402: system.l1_cntrl0: 1402 0 L1Cache L1_Replacement IMIM [0x4dc0, line 0x4dc0] 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement IMIM [0xdc0, line 0xdc0] 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement IMIM [0xdc0, line 0xdc0] On Wed, January 5, 2011 10:26 am, Beckmann, Brad wrote: 1. Below is a snip of a protocol trace that I recently used. I think it is important for us maintain that there is no DPRINTF information prepended to each line. The initial motivation for the protocol trace, was that tracing protocol transitions using standard debug print was too verbose. These traces can be 100’MB if not GBs in size, so reducing the information printed to each line is important. Nilay, could you send a snip of the trace with the patch applied? 2233850 3 L1Cache Load IIS [0x409ec0, line 0x409ec0] 2233850 3 L1Cache L2_Replacement MMI [0x40cfc0, line 0x40cfc0] 2233866 3 L1Cache Writeback_Ack MII [0x10bd40, line 0x10bd40] 2233866 3 L1Cache Writeback_Ack MII [0x40cfc0, line 0x40cfc0] 2234458 3 Seq Done [0x4033c3, line 0x4033c0] 3380 cycles 2234458 3 L1Cache Exclusive_Data IMMM_W [0x4033c0, line 0x4033c0] 0Directory-0 2234458 3 Seq Begin [0x40f883, line 0x40f880] ST 2234459 3 L1Cache All_acks_no_sharers MM_WMM [0x4033c0, line 0x4033c0] 2234508 3 L1Cache Exclusive_Data ISM_W [0x409ec0, line 0x409ec0] 0Directory-0 2234509 3 L1Cache All_acks_no_sharers M_WM [0x409ec0, line 0x409ec0] 2234510 3 L1Cache L1_to_L2 [0x4033c0, line 0x4033c0] 2234510 3 L1Cache Load IIS [0x407ec0, line 0x407ec0] 2234510 3 L1Cache L2_Replacement MMI [0x40b4c0, line 0x40b4c0] 2234510 3 L1Cache L1_to_L2 MM [0x409ec0, line 0x409ec0] 2234510 3 L1Cache Load IIS [0x100c40, line 0x100c40] 2234510 3 L1Cache L2_Replacement MMMI [0x4033c0, line 0x4033c0] 2. Just for my own knowledge… Nate, you mentioned that handling the SIGABRT signal is the right way to make this feature work for all of M5. Why is that? Is it just the preference not to use macros that overwrite the meaning of assert, or is it something more fundamental? Thanks, Brad From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, January 04, 2011 7:24 PM To: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert Cc: Nilay Vaish; Default; Beckmann, Brad Subject: Re: Review Request: ruby: get rid of ruby's Debug.hh This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/367/ On January 4th, 2011, 4:31 p.m., Brad Beckmann wrote: Hi Nate, I have a couple questions:
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
So if we explicitly handled the SIGABRT signal, we would only want to do that if we are running interactively, correct? If so, then we would still have some sort of conditional similar, if not the same as, the current conditional in the assert macro if (isatty(STDIN_FILENO)). If my understanding is correct, then we would still have multiple behaviors for assert. One when the running interactively and another when running in batch mode. Am I missing something? I just want to make sure I understand why we don't want to just move the current Ruby ASSERT macro into src/base/debug.hh (or some other file in src/base). Thanks, Brad From: bink...@gmail.com [mailto:bink...@gmail.com] On Behalf Of nathan binkert Sent: Wednesday, January 05, 2011 10:40 AM To: Beckmann, Brad Cc: Nilay Vaish; Steve Reinhardt; Ali Saidi; Gabe Black; Default Subject: Re: Review Request: ruby: get rid of ruby's Debug.hh 2. Just for my own knowledge... Nate, you mentioned that handling the SIGABRT signal is the right way to make this feature work for all of M5. Why is that? Is it just the preference not to use macros that overwrite the meaning of assert, or is it something more fundamental? Not fundamental. Mostly because we don't want multiple meanings of assert. It seems that if we could get this to work properly that it would be easiest as well. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] curTick global variable
It's a flexibility/fear-of-commitment thing... initially I wasn't positive which way I would go, and once I decided that curTick-as-EventQueue/Manager-field wasn't going to work well (too many places where it's pretty awkward to find the object pointer), I figured it would still be useful in case we need to use pthread_setspecific/getspecific on some platforms (OS X? OpenBSD? Cygwin?). Makes sense. I also kind of like how it indicates that curTick is not a normal variable... implicitly declaring it as part of TLS in one file without any indication at each reference that it's different seems potentially confusing. Good point. Why do you say that? Because you could put the EventQueue pointer in TLS too and not do the object-based lookup? I think it would be useful to check that the EventManager queue pointer and the TLS queue pointer are the same. Sounds good. TLS scares me, but maybe that's unnecessarily. :) Why? Because it's essentially global variable with somewhat complicated semantics, but if it's hidden, I'm cool. I haven't gotten that far yet, but yes, something like the locked external queue with async polling was what I was thinking of so far. I've been approaching it more top-down: what should simulate() look like, how do we do initialization, etc. Cool. I should dig up my code. Sure, I've got some time today late morning early afternoon if you're free. I'm in a meeting that will end in the next 15 mins to half hour. After that I've got nothing. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Is it possible to fix the width of the information prepended by DPRINTF? I would be great if we could maintain the current fixed width format. That might be hard (and may argue for DPRINTFN). In practice, when I want that, I usually just ensure that my object names end up not varying in length. e.g. system0.cpu0.l1_foo0. If I have more than 10 things, I make the name cpu00 or something like that. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
So if we explicitly handled the SIGABRT signal, we would only want to do that if we are running interactively, correct? If so, then we would still have some sort of conditional similar, if not the same as, the current conditional in the assert macro “if (isatty(STDIN_FILENO))”. If my understanding is correct, then we would still have multiple behaviors for assert. One when the running interactively and another when running in batch mode. Right. Though, we'd probably only handle the SIGABRT in the case of an interactive session as opposed to doing the check in the handler. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh
Yeah, that seems rather tedious. Let's just use DPRINTFN and maintain the current format. As long as the protocol trace format looks the same as before, I'm happy with the change. Brad -Original Message- From: bink...@gmail.com [mailto:bink...@gmail.com] On Behalf Of nathan binkert Sent: Wednesday, January 05, 2011 12:30 PM To: Beckmann, Brad Cc: M5 Developer List Subject: Re: [m5-dev] Review Request: ruby: get rid of ruby's Debug.hh Is it possible to fix the width of the information prepended by DPRINTF? I would be great if we could maintain the current fixed width format. That might be hard (and may argue for DPRINTFN). In practice, when I want that, I usually just ensure that my object names end up not varying in length. e.g. system0.cpu0.l1_foo0. If I have more than 10 things, I make the name cpu00 or something like that. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Hi Nilay, Lisa Hsu (another member of the lab here at AMD) and I were discussing these changes a bit more and there was one particular idea that came out of our conversation that I wanted to relay to you. Basically, we were thinking about how these changes will impact the flexibility of SLICC and we concluded that it is important to allow one to craft custom getCacheEntry functions for each protocol. I know initially I was hoping to generate these functions, but I now don’t think that is possible without restricting what protocols can be support by SLICC. Instead we can use these customized getCacheEntry functions to pass the cache entry to the actions via the trigger function. For those controllers that manage multiple cache memories, it is up to the programmer to understand what the cache entry pointer points to. That should eliminate the need to have multiple *cacheMemory_entry variables in the .sm files. Instead there is just the cache_entry variable that is set either by the trigger function call or set_cache_entry. Does that make sense to you? Brad From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, January 04, 2011 9:43 AM To: Nilay Vaish; Default; Beckmann, Brad Subject: Re: Review Request: Changing how CacheMemory interfaces with SLICC This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ On January 3rd, 2011, 3:31 p.m., Brad Beckmann wrote: Hi Nilay, First, I must say this is an impressive amount of work. You definitely got a lot done over holiday break. :) Overall, this set of patches is definitely close, but I want to see if we can take them a step forward. Also I have a few suggestions that may make things easier. Finally, I have a bunch of minor questions/suggestions on individual lines, but I’ll hold off on those until you can respond to my higher-level questions. The main thing I would like to see improved is not having to differentiate between “entry” and “entry_ptr” in the .sm files. Am I correct that the only functions in the .sm files that are passed an “entry_ptr” are “is_valid_ptr”, “getCacheEntry”, and “set_cache_entry”? If so, it seems that all three functions are generated with unique python code, either in an AST file or StateMachine.py. Therefore, could we just pass these functions “entry” and rely on the underneath python code to generate the correct references? This would make things more readable, “is_valid_ptr()” becomes “is_valid”, and it doesn’t require the slicc programmer to understand which functions take an entry pointer versus the entry itself. If we can’t make such a change, I worry about how much extra complexity this change pushes on the slicc programmer. Also another suggestion to make things more readable, please replace the name L1IcacheMemory_entry with L1I_entry. Do the same for L1D_entry and L2_entry. That will shorten many of your lines. So am I correct that hammer’s simultaneous usage of valid L1 and L2 cache entries in certain transitions is the only reason that within all actions, the getCacheEntry calls take multiple cache entries? If so, I think it would be fairly trivial to use a tbe entry as an intermediary between the L1 and L2 for those particular hammer transitions. That way only one cache entry is valid at any particular time, and we can simply use the variable cache_entry in the actions. That should clean things up a lot. By the way, once you check in these patches, the MESI_CMP_directory protocol will be deprecated, correct? If so, make sure you include a patch that removes it from the regression tester. Brad The main thing I would like to see improved is not having to differentiate between “entry†and “entry_ptr†in the .sm files. Am I correct that the only functions in the .sm files that are passed an “entry_ptr†are “is_valid_ptrâ€, “getCacheEntryâ€, and “set_cache_entryâ€? If so, it seems that all three functions are generated with unique python code, either in an AST file or StateMachine.py. Therefore, could we just pass these functions “entry†and rely on the underneath python code to generate the correct references? This would make things more readable, “is_valid_ptr()†becomes “is_validâ€, and it doesn’t require the slicc programmer to understand which functions take an entry pointer versus the entry itself. If we can’t make such a change, I worry about how much extra complexity this change pushes on the slicc programmer. There are functions that are passed cache entry and transaction buffer entry as arguments. Currently, I assume that these arguments are passed using pointers. Also another suggestion to make things more readable, please replace the name L1IcacheMemory_entry with L1I_entry. Do the same for L1D_entry and L2_entry. That will shorten many of your lines. The names of the cache entry variables are
