On Mon, Mar 05, 2007 at 04:06:29PM -0500, Vivek Thakkar wrote:
> 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.
>
Ok. That is what I expected.
>
> 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.
Is this a self monitoring program or are you monitoring another
thread? If so, are you using the PFM_CTX_FL_OVFL_BLOCK flag on the
context?
--
-Stephane
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
