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 > IM>IM [0x15c0, line 0x15c0] > 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement > IM>IM [0x3ac0, line 0x3ac0] > 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement > IM>IM [0x3ac0, line 0x3ac0] > 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement > IM>IM [0x3ac0, line 0x3ac0] > 1396: system.l1_cntrl1: 1396 1 L1Cache L1_Replacement > IM>IM [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 > IM>M [0x3ac0, line 0x3ac0] > 1397: system.l1_cntrl3: 1397 3 L1Cache L1_Replacement > IM>IM [0x15c0, line 0x15c0] > 1397: system.l2_cntrl0: 1397 0 L2CacheL2_Replacement_clean > MT_MB>MT_MB [0x3ac0, line 0x3ac0] > 1400: system.l2_cntrl0: 1400 0 L2Cache L1_GETX > MT_MB>MT_MB [0x400, line 0x400] > 1401: system.l2_cntrl0: 1401 0 L2CacheL2_Replacement_clean > MT_MB>MT_MB [0x3ac0, line 0x3ac0] > 1402: system.l1_cntrl0: 1402 0 L1Cache L1_Replacement > IM>IM [0x4dc0, line 0x4dc0] > 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement > IM>IM [0xdc0, line 0xdc0] > 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement > IM>IM [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 I>IS [0x409ec0, >> line 0x409ec0] >> 2233850 3 L1Cache L2_Replacement M>MI [0x40cfc0, >> line 0x40cfc0] >> 2233866 3 L1Cache Writeback_Ack MI>I [0x10bd40, >> line 0x10bd40] >> 2233866 3 L1Cache Writeback_Ack MI>I [0x40cfc0, >> line 0x40cfc0] >> 2234458 3 Seq Done > [0x4033c3, >> line 0x4033c0] 3380 cycles >> 2234458 3 L1Cache Exclusive_Data IM>MM_W [0x4033c0, >> line 0x4033c0] 0Directory-0 >> 2234458 3 Seq Begin > [0x40f883, >> line 0x40f880] ST >> 2234459 3 L1Cache All_acks_no_sharers MM_W>MM [0x4033c0, >> line 0x4033c0] >> 2234508 3 L1Cache Exclusive_Data IS>M_W [0x409ec0, >> line 0x409ec0] 0Directory-0 >> 2234509 3 L1Cache All_acks_no_sharers M_W>M [0x409ec0, >> line 0x409ec0] >> 2234510 3 L1Cache L1_to_L2 MM>MM [0x4033c0, >> line 0x4033c0] >> 2234510 3 L1Cache Load I>IS [0x407ec0, >> line 0x407ec0] >> 2234510 3 L1Cache L2_Replacement M>MI [0x40b4c0, >> line 0x40b4c0] >> 2234510 3 L1Cache L1_to_L2 M>M [0x409ec0, >> line 0x409ec0] >> 2234510 3 L1Cache Load I>IS [0x100c40, >> line 0x100c40] >> 2234510 3 L1Cache L2_Replacement MM>MI [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? >> > > -- > 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
