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

Reply via email to