(forgot to cc perfmon2-devel on my reply) "stephane eranian" <eran...@googlemail.com> wrote on 12/12/2008 04:03:51 PM:
> On Sat, Dec 13, 2008 at 12:57 AM, Corey J Ashford <cjash...@us.ibm.com> wrote: > > Thanks for the reply, Stephane. > > > > "stephane eranian" <eran...@googlemail.com> wrote on 12/11/2008 11:30:16 > > PM: > > > >> Corey, > >> > >> On Fri, Dec 12, 2008 at 4:08 AM, Corey J Ashford <cjash...@us.ibm.com> > > wrote: > >> > Thanks for the reply, Stephane, > >> > > >> > "stephane eranian" <eran...@googlemail.com> wrote on 12/11/2008 > > 05:35:21 > >> > PM: > >> > > >> >> Corey, > >> >> > >> >> On Fri, Dec 12, 2008 at 1:48 AM, Corey Ashford > >> >> <cjash...@linux.vnet.ibm.com> wrote: > >> >> > Hi Stephane, > >> >> > > >> >> > We are working through the example programs in the libpfm > > distribution > >> > and > >> >> > came across multiplex.c and multiplex2.c > >> >> > > >> >> > After fixing a superficial problem with get_cpu_speed(), we find > > that > >> > on > >> >> > ppc970mp we are getting an error in pfm_write_pmds, where the > >> > smpl_pmds > >> >> > field is set to some large (bogus) value and is causing the program > > to > >> > exit > >> >> > with an error. Similarly, on Power6, this same test is exiting > > with > >> > an > >> >> > error in pfm_write_pmcs, where the flags are set to an illegal > > value. > >> >> > > >> >> > Looking more carefully at the test, it appears to be pretty old and > >> > may > >> >> > pre-date the multiplexing built into perfmon itself. > >> >> > > >> >> That is correct. > >> >> > >> >> > Is this example still valid? Would you expect it to run on other > >> > hardware > >> >> > with modification? It looks like it was designed for Itanium > >> > initially. > >> >> > > >> >> I think you can ignore that program for now. I know it has problems. > > I > >> > fixed > >> >> some of them but clearly there are others. I am assuming your looking > > at > >> >> the current CVS code, right? > >> > > >> > Yes. Looking a bit further, I see that a call to calloc is made for > > the > >> > pmcs and pmds arrays, so I'm not sure how we're ending up with bogus > >> > values in those fields. > >> > > >> The idea of multiplex was to show how to time multiplex counters at > >> the user level. > >> So this still needs to work. I will take a look next week. > >> > >> > For the time being though, I'm going to lower the priority of fixing > > this > >> > one. Multiplex2 does work fine on both ppc970 and power6. > >> > > >> Does it work for both time multiplexing and overflow multiplexing > > (--ovfl-sw)? > > > > Yes, sort of. With just the --ovfl-sw, it wanted to use a multiplexing > > rate based on the resolution of the timer, which is this case is 1ns. I > > then tried 'multiplex2 --ovfl-sw --freq=100 ./loop' (loop is just a > > program that loops doing fp multiplies), and got this result: > > > > gloop6:corey-41% ./multiplex2 --freq=100 --ovfl-sw ./loop > > clock_res=1ns(1000000000.00Hz) ask period=10000000ns(100.00Hz) get > > period=10000000ns(100.00Hz) > > # 100.00Hz period = 10000000nsecs > > # 40050000 cycles @ 4005 MHz > > # using overflow-based multiplexing > > # 2 sets > > # 841.50 average run per set > > # 8437784726.00 average ns per set > > # set measured total #runs scaled total event name > > # ------------------------------------------------------------------ > > 000 18446744073681458963 842 9223372036854775807 PM_RUN_CYC > > 001 8230525967 841 16465275434 PM_INST_CMPL > > > > This looks very bogus. :( > > > > Indeed! > > is this a 32-bit or 64-bit binary? > The 2nd line looks fine, though. Is this related in anyway > to the business of the counters which do not interrupt on overflow? I don't think so, but I will look into that to make sure. That occurred to me immediately too. The reason I think they should not be involved is that the privilege level that is being used by default - PLM3 - precludes the use of counters 5 & 6, which are the non-interrupting counters - they count in only PLM3|PLM1|PLM0 mode only. > > In overflow, switching, the program adds the cycle event to each set and > it is used to overflow and trigger the switch. > > Question: is it possible to measure cycles twice on your machine? You mean in two different counters? Yes, in one configuration. There are some groups which can count cycles in counters 1-4 which are interrupt-capable. The current libpfm code will not allow mixed-privilege level counting. All groups include counters 5 & 6, so if you do count in PLM3|PLM1|PLM0 mode, you could count cycles on counter 1 and counter 5 simultaneously. However, the current libpfm won't deal with this case like you might like: when looking for a cycles counter, it will find counter 1 twice. Is using two separate counters for this case required? It sounds like it is, since one counts while the other one overflows. > > > Without --ovfl-sw, I get: > > > > # 100.00Hz period = 10000000nsecs > > # 40050000 cycles @ 4005 MHz > > # using time-based multiplexing > > # 10000000 nsecs effective switch timeout > > # 2 sets > > # 844.00 average run per set > > # 8438576482.00 average ns per set > > # set measured total #runs scaled total event name > > # ------------------------------------------------------------------ > > 000 33692761774 844 67374083670 PM_RUN_CYC > > 001 8230855653 844 16464506920 PM_INST_CMPL > > > > > > Regards, > > > > - Corey > > > > Corey Ashford > > Software Engineer > > IBM Linux Technology Center, Linux Toolchain > > Beaverton, OR > > 503-578-3507 > > cjash...@us.ibm.com > > > > ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
