John and Will,
Thanks very much for your fast answers on OProfile interrupts and sessions.
It was very helpful ! I have a question related to some specific
counter-events and I'm wondering if you know the answer or can point to me
to someone who might have the answer. Please feel free to ignore me if you
are too busy to answer this.
One of our objectives is to find out if our software is saturating the
memory bus (frontside bus). We monitored BUS_TRAN_MEM event on a two
processor machine (Pentium III Xeon, HLE3 chipset) and used the following
formula to calculate the total amount of data transfer on the bus.
DT = Data transfer MB / sec
S = Number of samples (BUS_TRAN_MEM)
M = Samples multiplier (ctr0-count=M)
32 = Cache line size on Pentium III Xeon (can it ever be more ? or less ?)
60 = Interval for sample collection (number of seconds)
DT = S * M * 32 / 60 / 1024 / 1024
We also tried get the same numbers using other events (L2_LINES_IN and
S1 = Samples for L2_LINES_IN
S2 = Samples for L2_LINES_OUT
DT = (S1 + S2) * M * 32 / 60 / 1024 / 1024
Are these calculations correct ? Can we ever transfer less than 32 bytes per
bus transaction ? Can we transfer more than 32 bytes per bus transaction ?
I would appreciate your help (answers and/or pointers) very much.
Thanks and regards.
From: John Levon [mailto:levon@...]
Sent: Wednesday, September 11, 2002 6:55 PM
To: Satish Katiyar
Subject: Re: OProfile interrupts
On Wed, Sep 11, 2002 at 06:49:10PM -0700, Satish Katiyar wrote:
> How do you reset the event counting ? If I start the profiler (op_start)
> with CPU_CLK_UNHALTED event on ctr0, stop it (using op_stop) and then
> start with the same event, the number of events reported are not the
> between the last stop and the current start - it's the sum of events in
> current session and the previous sessions. The only workaround I have
> is to change the event type, which does reset the counter. I'm sure
> a better way to do this. Any ideas ?
rm -rf /var/lib/oprofile (make sure oprofile has stopped entirely)
Either will do.
> Processor uses interrupts to communicate to OProfile the fact that the
> counter has overflowed (or under flowed). When I'm running OProfile,
> shouldn't I see many more interrupts generated in the system because of
> than the normal number of interrupts ? I don't see any change in the
> of interrupts reported by vmstat and sar !
They are (usually) NMI interrupts, but are not counted as usual so won't
appear in the counts in /proc/interrupts