All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.