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
