From: Ingo Molnar <mingo@elte.hu>
To: David Ahern <dsahern@gmail.com>
Cc: Vince Weaver <vweaver1@eecs.utk.edu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, paulus@samba.org, acme@redhat.com
Subject: Re: perf: regression -- missing /sys/devices/system/cpu/perf_events
Date: Tue, 24 May 2011 23:29:25 +0200 [thread overview]
Message-ID: <20110524212925.GL27634@elte.hu> (raw)
In-Reply-To: <4DDC1BB2.4090503@gmail.com>
* David Ahern <dsahern@gmail.com> wrote:
> On 05/24/11 14:12, Vince Weaver wrote:
> > On Tue, 24 May 2011, Ingo Molnar wrote:
> >>
> >> So, what is wrong with the method Peter suggested: the presence of the perf
> >> syscall (it not returning -ENOSYS) is bona fide evidence that perf is
> >> available.
> >
> > it's just hard to do that from a shell script.
>
> What about kallsyms:
>
> grep sys_perf_event_open /proc/kallsyms
that looks pretty roundabout and expensive - kallsyms can be large.
Nor is there a guarantee that the function will always be called
sys_perf_event_open() - we already renamed it from sys_perf_counter_open() as
you yourself mentioned it :-)
Plus the kernel can be built without /proc/kallsyms, and root can chmod off the
file permissions of /proc/kallsyms for unprivileged user-space as well. So it's
not a particularly robust check.
I agree with Vince that as far as shell scripts are concerned, checking
/proc/sys/kernel/perf_event_paranoid would work best - and it works better than
having to check the perf syscall.
Vince: mind sending a patch that adds a comment to perf_event_paranoid that
userspace relies on the existence of that file as a feature check? Having such
reminders in the code works even better than frequent testing ;-)
As far as the actual PAPI library goes i really hope it checks the syscall
itself: that's much faster and more robust than an
access("/proc/sys/kernel/perf_event_paranoid") call ...
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-24 21:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 13:59 perf: regression -- missing /sys/devices/system/cpu/perf_events Vince Weaver
2011-05-24 14:11 ` Peter Zijlstra
2011-05-24 17:42 ` Vince Weaver
2011-05-24 19:48 ` Ingo Molnar
2011-05-24 20:12 ` Vince Weaver
2011-05-24 20:57 ` David Ahern
2011-05-24 21:29 ` Ingo Molnar [this message]
2011-06-03 21:54 ` [patch] perf - comment /proc/sys/kernel/perf_event_paranoid to be part of user ABI Vince Weaver
2011-06-04 10:23 ` Ingo Molnar
2011-06-04 11:06 ` [tip:perf/core] perf: Comment " tip-bot for Vince Weaver
2011-05-24 21:37 ` perf: regression -- missing /sys/devices/system/cpu/perf_events Ingo Molnar
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=20110524212925.GL27634@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=dsahern@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=vweaver1@eecs.utk.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.