I had previously posted a patch to update callgraph documentation for
the opcontrol man page and for the web site's FAQ, but I missed updating
the user guide. This patch corrects that oversight.
John, if you approve the patch, I can take care of the mechanics of
committing it.
Regards.
-Maynard

On Fri, Nov 17, 2006 at 03:28:53PM -0800, Dave Nomura wrote:
> Attached is the patch that implements the -X (--xml) option to
> opreport to cause XML to be generated instead of plain text. The patch
> contains all of the modifications in response to your most recent e-mails.
Applied. Thanks a lot!
Now when do we get the OProfile GUI :)
regards
john

John,
Attached is the patch that implements the -X (--xml) option to
opreport to cause XML to be generated instead of plain text. The patch
contains all of the modifications in response to your most recent e-mails.
Thanks for all of your work.
--
Dave Nomura
LTC Linux Power Toolchain

John Levon wrote:
> On Fri, Nov 17, 2006 at 12:29:17PM -0500, William Cohen wrote:
>
>
>>The algorithm won't work if there are counters already allocated.
>>Shouldn't the code be the following?
>
>
> jeremiah.lott@... sent the exact same patch. I never found time
> to review it, so the fact you've got the exact same patch counts as a
> review :) Fine by me.
>
> regards
> john
The correction by Jeremiah Lott has been checked in. The next step was
generationg code that doesn't assume that all the performance counters are
available. The attached patch checkes the /dev/oprofile directory to see what
counters are actually available to oprofile and marks them available in the bit
mask so map_event_to_counter doesn't use counters that are unavailable. The
following patch seems to address the conflict with the watchdog timer observed
with the 2.6.19 kernels.
-Will
2006-11-17 Will Cohen <wcohen@...>
* libop/op_alloc_counter.c (op_get_counter_mask,perfcounterdir):
check to see what performance counters are actually available.

On Fri, 17 Nov 2006 11:29:25 +0100, Andi Kleen wrote:
>On Friday 17 November 2006 10:59, Mikael Pettersson wrote:
>
>> It certainly worked when I originally implemented it.
>
>I don't think so. NMI watchdog never recovered no matter if oprofile
>used the counter or not.
If so then that's a bug in oprofile or the x86-64 kernel.
I just checked the 2.6.18 i386 kernel + the perfctr kernel
extension, and the NMI watchdog did start ticking again when
perfctr called release_lapic_nmi().
Before the {reserve,release}_lapic_nmi() API went into the
kernel the NMI watchdog might not have resumed, but that was
ages ago (the 2.6.6 kernel).
/Mikael

On Fri, Nov 17, 2006 at 12:29:17PM -0500, William Cohen wrote:
> The algorithm won't work if there are counters already allocated.
> Shouldn't the code be the following?
jeremiah.lott@... sent the exact same patch. I never found time
to review it, so the fact you've got the exact same patch counts as a
review :) Fine by me.
regards
john

OProfile figures out what registers are available strictly from the
cpu type information. This works when OProfile is the only thing using
the performance monitoring hardware.
Recent change to the Linux 2.6.19 reserve a performance counter for
the watchdog timer via reserve_pffctr_nmi(), and there are other
possible users of the performance monitoring hardware,
e.g. perfmon2. The oprofile driver in the kernel makes the available
performance counters visible in /dev/oprofile/. On the x86-64 the
watchdog appears to take performance counter 0, leaving registers 1,
2, and 3 available.
The oprofile allocation code needs some modification to be able to
handle the case where some of the performance counters are not
available. The ophelp code calls map_event_to_counter in
libop/op_alloc_counter.c. This function in turn calls
allocate_counter. The fourth argument to allocate_counter is a bit
mask indicating that all the performance counters are available.
Would it be reasonable to allow the fourth argument be a possibly
non-zero bitmask, indicating which counters are already
unavailable. This information would be obtained by scanning the
/dev/oprofile directory for numbered directories. Mark the found
numbered directories in bit vector as zero and everything else and
unavailable.
The algorithm won't work if there are counters already allocated.
Shouldn't the code be the following?
Index: libop/op_alloc_counter.c
===================================================================
RCS file: /cvsroot/oprofile/oprofile/libop/op_alloc_counter.c,v
retrieving revision 1.6
diff -u -r1.6 op_alloc_counter.c
--- libop/op_alloc_counter.c 1 Oct 2003 21:53:46 -0000 1.6
+++ libop/op_alloc_counter.c 17 Nov 2006 17:03:04 -0000
@@ -130,7 +130,7 @@
counter_arc const * arc = list_entry(pos, counter_arc, next);
if (allocated_mask & (1 << arc->counter))
- return 0;
+ continue;
counter_map[depth] = arc->counter;
The other issue that will need to be addressed is the sharing of the
performance counter interrupt in the kernel. The there could be
different handlers for the different counters, e.g. one handler for
the watchdog timer and different handler for the regular oprofile
sampling.
-Will

On Friday 17 November 2006 10:59, Mikael Pettersson wrote:
> It certainly worked when I originally implemented it.
I don't think so. NMI watchdog never recovered no matter if oprofile
used the counter or not.
-Andi

On Fri, 17 Nov 2006 10:59:07 +0100
Mikael Pettersson <mikpe@...> wrote:
> Andrew Morton writes:
> > On Thu, 16 Nov 2006 11:55:46 +0100
> > Mikael Pettersson <mikpe@...> wrote:
> >
> > > Andrew Morton writes:
> > > > Surely the appropriate behaviour is to allow oprofile to steal the NMI and
> > > > to then put the NMI back to doing the watchdog thing after oprofile has
> > > > finished with it.
> > >
> > > Which is _exactly_ what pre-2.6.19-rc1 kernels did. I implemented
> > > the in-kernel API allowing real performance counter drivers like
> > > oprofile (and perfctr) to claim the HW from the NMI watchdog,
> > > do their work, and then release it which resumed the watchdog.
> >
> > OK. But from Andi's comments it seems that the NMI watchdog was failing to
> > resume its operation.
>
> It certainly worked when I originally implemented it. If it didn't work
> that way before 2.6.19-rc1 butchered it then that would have been a bug
> that should have been fixed.
Oh. OK.
Meanwhile, 2.6.19-rc6 remains unfixed.

Andrew Morton writes:
> On Thu, 16 Nov 2006 11:55:46 +0100
> Mikael Pettersson <mikpe@...> wrote:
>
> > Andrew Morton writes:
> > > Surely the appropriate behaviour is to allow oprofile to steal the NMI and
> > > to then put the NMI back to doing the watchdog thing after oprofile has
> > > finished with it.
> >
> > Which is _exactly_ what pre-2.6.19-rc1 kernels did. I implemented
> > the in-kernel API allowing real performance counter drivers like
> > oprofile (and perfctr) to claim the HW from the NMI watchdog,
> > do their work, and then release it which resumed the watchdog.
>
> OK. But from Andi's comments it seems that the NMI watchdog was failing to
> resume its operation.
It certainly worked when I originally implemented it. If it didn't work
that way before 2.6.19-rc1 butchered it then that would have been a bug
that should have been fixed.

Hi, I am fairly newbie to this. I am trying to profile kernel modules
for optimization.=20
=20
I am currently running on this system.
uname -a
Linux svbu-vm-host-1 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006
i686 i686 i386 GNU/Linux
My version of oprofile is 0.9.2
When trying to: opcontrol --callgraph=3D1
I get this error message: Call-graph profiling unsupported on this
kernel/hardware
=20
Everywhere I looked seems to indicate that I should be getting callgraph
support. Is there something missing that I need to do in order to get
callgraphs
=20
Thank you for your help and time in advance.
=20
Wen Shu Tang
=20
Wen Shu Tang
=20

This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 72 hours on the queue on externalmx-1.sourceforge.net.
The message identifier is: 1Gjgyg-0002EW-KA
The subject of the message is: unto Ruth Samuel ministered unto you as the guard sight that is
The date of the message is: Mon, 13 Nov 2006 22:56:08 +0400
The address to which the message has not yet been delivered is:
oprofile-list@...
Delay reason: SMTP error from remote mailer after RCPT TO:<oprofile-list@...>:
host mail.sourceforge.net [66.35.250.206]: 451-Could not complete sender verify callout
451-Could not complete sender verify callout for
451-<oprofile-list@...>.
451-The mail server(s) for the domain may be temporarily unreachable, or
451-they may be permanently unreachable from this server. In the latter case,
451-you need to change the address or create an MX record for its domain
451-if it is suppos
No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.

Hello,
On Thu, Nov 16, 2006 at 10:34:56AM -0500, William Cohen wrote:
>
> Is this going to require sharing the nmi interrupt and knowing which perfcounter
> register triggered the interrupt to get the correct action? Currently the
> oprofile interrupt handler assumes any performance monitoring counter it sees
> overflowing is something it should count.
>
Yes, you need to share the NMI interrupt. In my next perfmon patch you will
see that this can be made to work. You just need to add one check in the
NMI handler callback: is it for me or else try perfmon? Perfmon can auto-detect
if NMI is active and give up the right counter (there is an API to check
what is reserved). The interface propagates the list of available counters
to apps which then pass the information onto libpfm which tries to use
the remaining counters.
--
-Stephane

On Thu, 16 Nov 2006 11:55:46 +0100
Mikael Pettersson <mikpe@...> wrote:
> Andrew Morton writes:
> > Surely the appropriate behaviour is to allow oprofile to steal the NMI and
> > to then put the NMI back to doing the watchdog thing after oprofile has
> > finished with it.
>
> Which is _exactly_ what pre-2.6.19-rc1 kernels did. I implemented
> the in-kernel API allowing real performance counter drivers like
> oprofile (and perfctr) to claim the HW from the NMI watchdog,
> do their work, and then release it which resumed the watchdog.
OK. But from Andi's comments it seems that the NMI watchdog was failing to
resume its operation.
> Note that oprofile (and perfctr) didn't do anything behind the
> NMI watchdog's back. They went via the API. Nothing dodgy going on.

Based on review comments received so far, we will be posting an updated
kernel patch for OProfile for Cell. Most notably, this patch removes
some racey conditions between our "virtual counter" function and the
interrupt handler, as well as fixing the way we were restarting and
stopping our timer for the virtual counter.
Thanks.
-Maynard
Maynard Johnson wrote:
> Hello,
> I will be posting a patch that updates the OProfile kernel driver to
> enable it for the Cell Broadband Engine processor. The patch is based
> on Arnd Bergmann's arnd6 patchset for 2.6.18
> (http://kernel.org/pub/linux/kernel/people/arnd/patches/2.6.18-arnd6/),
> with Kevin Corry's cbe_pmu_interrupt patch on applied on top. Kevin
> Corry's patch was submitted to the mailing lists earlier today and can
> be found at:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116360639928471&w=2).
>
> I will also post an OProfile userpsace patch to the oprofile-list that
> adds the necessary support for the Cell processor.
>
> Thanks in advance for your review of this patch.
>
> Maynard Johnson
> LTC Power Linux Toolchain
> 507-253-2650
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@...
> https://lists.sourceforge.net/lists/listinfo/oprofile-list

> What other purposes do you see the performance counters useful for?
Export one to user space as a cycle counter for benchmarking. RDTSC doesn't
do this job anymore.
> To collect information on process characteristics so they can be scheduled more efficiently?
That might happen at some point in the future, but i would expect
us to wait for CPUs with more performance counters first.
> Is this going to require sharing the nmi interrupt and knowing which perfcounter
> register triggered the interrupt to get the correct action? Currently the
> oprofile interrupt handler assumes any performance monitoring counter it sees
> overflowing is something it should count.
Yes. That needs to be fixed.
-Andi

Andi Kleen wrote:
> On Thursday 16 November 2006 06:05, Andrew Morton wrote:
>
>>On Thu, 16 Nov 2006 04:21:09 +0100
>>Andi Kleen <ak@...> wrote:
>>
>>
>>>>If it's really true that oprofile is simply busted then that's a serious
>>>>problem and we should find some way of unbusting it. If that means just
>>>>adding a dummy "0" entry which always returns zero or something like that,
>>>>then fine.
>>>
>>>That could be probably done.
>>
>>I'm told that this is exactly what it was doing before it got changed.
>
>
> Hmm, ok perhaps that can be arranged again.
>
> The trouble is that I want to use this performance counter for
> other purposes too, so we would run into trouble again
> if oprofile keeps stealing it.
What other purposes do you see the performance counters useful for? To collect
information on process characteristics so they can be scheduled more efficiently?
Is this going to require sharing the nmi interrupt and knowing which perfcounter
register triggered the interrupt to get the correct action? Currently the
oprofile interrupt handler assumes any performance monitoring counter it sees
overflowing is something it should count.
-Will

Bugs item #1597752, was opened at 2006-11-16 17:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1597752&group_id=16191
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexander Monakov (a_monakov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Count discrepancy in ia64 assembly annotation
Initial Comment:
Total hit count displayed by "opannotate -a" does not match sum of counts for each of the bundles in function (total count exceeds the sum by approx. 20%).
However, running the same workload under HP Caliper profiler shows almost the same total hit count, but different counts for some of the bundles (those counts are greater than the corresponding counts listed by opannotate).
Therefore, I suspect that oprofile somehow missed many hits on those bundles.
I would also like to note that such bundles have stop bit in the middle of the bundle -- is it possible that oprofile does not handle that properly?
Attaching test case assembly; source, opannotate -a output and caliper output will follow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1597752&group_id=16191

Andrew Morton writes:
> Surely the appropriate behaviour is to allow oprofile to steal the NMI and
> to then put the NMI back to doing the watchdog thing after oprofile has
> finished with it.
Which is _exactly_ what pre-2.6.19-rc1 kernels did. I implemented
the in-kernel API allowing real performance counter drivers like
oprofile (and perfctr) to claim the HW from the NMI watchdog,
do their work, and then release it which resumed the watchdog.
Note that oprofile (and perfctr) didn't do anything behind the
NMI watchdog's back. They went via the API. Nothing dodgy going on.

On Thursday 16 November 2006 06:05, Andrew Morton wrote:
> On Thu, 16 Nov 2006 04:21:09 +0100
> Andi Kleen <ak@...> wrote:
>
> > >
> > > If it's really true that oprofile is simply busted then that's a serious
> > > problem and we should find some way of unbusting it. If that means just
> > > adding a dummy "0" entry which always returns zero or something like that,
> > > then fine.
> >
> > That could be probably done.
>
> I'm told that this is exactly what it was doing before it got changed.
Hmm, ok perhaps that can be arranged again.
The trouble is that I want to use this performance counter for
other purposes too, so we would run into trouble again
if oprofile keeps stealing it.
> > > But we can't just go and bust it.
> >
> > It just did something unbelievable broken before.
>
> What did it do?
Silently kill the nmi watchdog.
>
> > I would say it busted
> > itself.
>
> It gave profiles, which was fairly handy.
I'm sure it can be fixed there. Ok ok I keep sounding like a sysfs maintainer
now @)
-Andi

40 messages has been excluded from this view by a project administrator.