From: William Cohen <wcohen@redhat.com>
To: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: "linux-perf-use." <linux-perf-users@vger.kernel.org>
Subject: Re: perf software events broken in containers
Date: Wed, 22 Mar 2017 16:29:54 -0400 [thread overview]
Message-ID: <4bf76843-d25e-4cda-30ce-0984f8778704@redhat.com> (raw)
In-Reply-To: <CAE40pdd06QXckEMYfU63c=Zvrrn22A-sm-Sh37CymR5rpJZ57Q@mail.gmail.com>
On 03/22/2017 03:59 PM, Brendan Gregg wrote:
> G'Day Will,
>
> On Wed, Mar 22, 2017 at 12:15 PM, William Cohen <wcohen@redhat.com> wrote:
>> On 03/22/2017 02:24 PM, Brendan Gregg wrote:
>>> G'Day,
> [...]
>>>
>>> The kernel is returning errno 1 to the sys_perf_event_open() call in
>>> __perf_evsel__open(). I'm trying to find out which kernel function
>>> throws the EPERM, but almost nothing is tracable via ftrace/kprobes.
>>> It's pretty annoying... Thanks for any ideas,
>>
>> Hi Brendan,
>>
>> Several years ago I had a problem with the perf_event_open not working on arm machines. I looked at the kernel source code and just kept putting systemtap one-liners like the following on the various functions used by the perf_event_open to see which function was the one returning the error code:
>>
>> stap -v -e 'probe kernel.function("idr_find").return {printf("%s %s 0x%x\n", pn(), $$parms$, $return)}'
>>
>
> Right, I've been doing that with ftrace/kprobes/bcc/BPF... Many of the
> functions aren't visible, though, I suspect inlined.
>
Hi Brendan,
Yes, the inlined functions are going to make it hard to get some of the return values. However, you can probably narrow down the boundary between executed functions and not executed functions. Would the Intel Processor Trace (http://halobates.de/blog/) be usable to help track down this problem?
-Will
next prev parent reply other threads:[~2017-03-22 20:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 18:24 perf software events broken in containers Brendan Gregg
2017-03-22 19:15 ` William Cohen
2017-03-22 19:59 ` Brendan Gregg
2017-03-22 20:29 ` William Cohen [this message]
2017-03-22 21:35 ` Brendan Gregg
2017-03-23 14:21 ` David Ahern
2017-03-27 16:10 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4bf76843-d25e-4cda-30ce-0984f8778704@redhat.com \
--to=wcohen@redhat.com \
--cc=brendan.d.gregg@gmail.com \
--cc=linux-perf-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).