Hi Stephane,
> Vivek,
>
> On Sun, Mar 04, 2007 at 07:22:34PM -0500, Vivek Thakkar wrote:
>>
>> Hi,
>>
>> One of the functions in smpl_pebs.c is "process_smpl_buf " . It has a
>> check
>> condition (modified slightly for running with multiple threads) as
>> follows :
>>
>> if (hdr->hdr_overflows <= last_overflow[id] && last_overflow[id] != ~0)
>> {
>> warning("skipping identical set of samples %"PRIu64" <=
>> %"PRIu64"\n",
>> hdr->hdr_overflows, last_overflow);
>> return;
>> }
>> /*In my case this condition gets executed individually for each thread -
>> last_overflow[id] is an array for thread with thread # id, argument hdr
>> is
>> passed in the function and is unique for each thread */
>>
>> Here, hdr->hdr_overflows should be monotonically increasing (across
>> multiple function invocations) for each thread. But somewhere in the
>> middle, I notice a spike in its value (described below).
>> Because of it , all the following invocations of this function just
>> return
>> without counting samples. Now, I can hack it pretty easily by just
>> updating the last_overflow[id] to the current hdr->hdr_overflows
>> (treating
>> that one value as unexpected). But I would like to understand the reason
>> for this. Is this a bug in perfmon ?
>
> Could you try this on 2.6.20 with the latest perfmon patches?
>
> Another thing you can do is check the perfmon statistics. in PEBS
> mode, the number of buffer overflows = number of PMU interrupts.
> So if you have 2 identical threads and they each see 2000 buffer
> overflows,
> the total number of PMU interrupts as reported by:
> /sys/devices/system/cpu/cpu*/perfmon/ovfl_intr_all-count
> should be 4000 total of all your cpus.
>
> You can reset the stats by doing:
> # echo 1 > /sys/kernel/perfmon/reset
>
Thanks for the suggestion. Yes, total number of interrupts match the
number of overflows.
>> I am using perfmon patched 2.6.17 kernel.
>>
>> Following header overflows((hdr->hdr_overflows) have been tracked only
>> for
>> thread 0. And the test program was run for 2 threads.
>>
>> Header overflow = 1781
>> Header overflow = 1782
>> Header overflow = 1783
>> Header overflow = 1784
>> Header overflow = 1785
>> Header overflow = 1786
>> Header overflow = 1787
>> Header overflow = 1788
>> Header overflow = 1789
>> <<<<<<<<<<<<<<<<< Header overflow = 2947 >>>>>>>>>>>>>>>>>>>>>>>>>>
>> Header overflow = 1790
>> Header overflow = 1791
>> Header overflow = 1792
>> Header overflow = 1793
>> Header overflow = 1794
>> Header overflow = 1795
>> Header overflow = 1796
>> Header overflow = 1797
>> Header overflow = 1798
>> Header overflow = 1799
>> Header overflow = 1800
But then what could be the cause for a sudden spike in the value of header
overflow ? I will try and test it with 2.6.20 once i get that kernel
ready.
Thanks for your response though !!
>> --
>> Regards,
>> Vivek Thakkar
>>
>> Regards,
>> Vivek
>> ---------------------
>> MS, CSC Department
>> NC State University
>>
>> 2834 Avent Ferry Road, Apt. 202
>> Raleigh, NC, 27606
>> _______________________________________________
>> perfmon mailing list
>> [email protected]
>> http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
>
> --
>
> -Stephane
>
Regards,
Vivek
---------------------
MS, CSC Department
NC State University
2834 Avent Ferry Road, Apt. 202
Raleigh, NC, 27606
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
