Hello, yeah, my mistake. It is POWER5 indeed.
I was looking a bit more into it and I found a way which seems to solve the problem (although I am not sure it is the proper way to fix it). In file perfmon/perfmon_ctxsw.c, lines 241-242 there is: if (need_save_pmds) pfm_save_pmds(ctx, set); If I remove the check for need_save_pmds, and unconditionally save the PMDS I cannot reproduce the problem anymore. I hope this can help to find the problem. Thank you! Victor On Wed, May 20, 2009 at 1:35 AM, Corey J Ashford <cjash...@us.ibm.com> wrote: > victor jimenez <betaband...@gmail.com> wrote on 05/19/2009 09:25:38 AM: > >> Hello, >> >> I realized that the log may not look nicely, so I am attaching it as a >> text file. >> >> Victor >> >> On Tue, May 19, 2009 at 6:17 PM, victor jimenez <betaband...@gmail.com> > wrote: >> > Hello, >> > >> > I am using perfmon2 on IBM POWER5. >> > The version I am using is libpfm 3.8 with kernel 2.6.28 (February >> > 19th, 2009 release). >> > >> > My problem is that between two consecutives readings of the counters I >> > get decreasing values. For instance, I want to read the number of >> > misses in L2, so I read the counter PM_DATA_FROM_L2MISS. In reading >> > 'i' I get 59695 and in reading 'i+1' I get 59637. >> > >> > I am wondering if this is a bug or it is some sort of limitation. >> > However, in my opinion it looks like a bug. >> > >> > In order to understand what was going on, I modified the kernel to >> > print some messages. In the log at the end of the mail the meaning of >> > the fields in every line is: >> > >> > pfm_xxx : the function from where the message is printed >> > pid : pid of the process which is printing the message >> > task : parameter task which is present in some perfmon2 functions >> > ctx : parameter/variable task which is present in some perfmon2 > functions >> > cnum : counter number >> > value : value which is being written into the PMDS >> > result : value readed from the PMDS >> > >> > About the pid field, in my experiment I am running two processes >> > (2488, 2489) only 2489 is using perfmon2 (i.e., there is only one >> > pfm_context). >> > >> > In my opinion, the problem comes because perfmon2 sometimes does not >> > save PMDS right before a context switch. >> > >> > For instance, in the next log, at line 1 process 2489 is switched out >> > and in line 6 and 8 pfm_save_pmds is called. The value which is being >> > saved for counter 3 is 58339. At line 20 the user reads the counter >> > with the call to sys_pfm_read_pmds and the value returned is 59695. >> > >> > The problem is that at line 26 when process 2489 is switched out >> > again, the PMDS are not saved. And they are being restored at line 30 >> > with the old value which was saved before (58339). >> > >> > After that, the counters keep increasing until we read them again at >> > line 103. The value read there is 59637, which is smaller than the >> > previous reading (59695). >> > > > [snip] > Hello Victor, > > Thank you very much for reporting this. You are right that it does appear > to be a bug. I will look into > this tomorrow. Thank you for providing such detailed information. > > Just to be clear, we are talking about Power5, right? The subject line > says Power6, but that appears to be a typo, > given the log you have provided. > > Regards, > > - Corey > > Corey Ashford > Software Engineer > IBM Linux Technology Center, Linux Toolchain > Beaverton, OR > 503-578-3507 > cjash...@us.ibm.com > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel