I tried compiling tools/perf in an old linux source tree (ab86e5765,
roughly 2.6.31), and the resulting perf tool seemed to work fine
("perf record" ... "perf report", "perf stat" etc); I ran it as an
ordinary user.
Next I updated to the latest linus tree (c5974b835a), and recompiled perf.
It still seems to work, and has obviously had a lot of features added, but
now it only wants to let me run "perf record" if I'm root. This is
slightly annoying -- even if I use "sudo" or make it setuid, it still ends
up generating an output file owned by root, etc.
In both cases, I'm using the same kernel (I only recompiled the tool), 2.6.32.
I used no options with "perf record", just gave the command I wanted to profile.
Is there a reason why the newer version perf tool restricts "perf record"
to root, especially given that the older version still seems to work fine
as non-root?
Thanks,
-Miles
--
Run away! Run away!
Em Wed, Jan 06, 2010 at 02:32:17PM +0900, Miles Bader escreveu:
> I tried compiling tools/perf in an old linux source tree (ab86e5765,
> roughly 2.6.31), and the resulting perf tool seemed to work fine
> ("perf record" ... "perf report", "perf stat" etc); I ran it as an
> ordinary user.
>
> Next I updated to the latest linus tree (c5974b835a), and recompiled perf.
> It still seems to work, and has obviously had a lot of features added, but
> now it only wants to let me run "perf record" if I'm root. This is
> slightly annoying -- even if I use "sudo" or make it setuid, it still ends
> up generating an output file owned by root, etc.
>
> In both cases, I'm using the same kernel (I only recompiled the tool), 2.6.32.
>
> I used no options with "perf record", just gave the command I wanted to profile.
>
> Is there a reason why the newer version perf tool restricts "perf record"
> to root, especially given that the older version still seems to work fine
> as non-root?
Don't recall noticing such problem, here it works just fine:
[acme@doppio linux-2.6-tip]$ mkdir tmp
[acme@doppio linux-2.6-tip]$ cd tmp
[acme@doppio tmp]$ time perf record find ~/git/ > /dev/null
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.053 MB perf.data (~2312 samples) ]
real 0m25.602s
user 0m0.007s
sys 0m0.020s
[acme@doppio tmp]$ perf report | head -13
# Samples: 1628008142
#
# Overhead Command Shared Object Symbol
# ........ ....... ...................... ......
#
6.03% find libc-2.10.2.so [.] _IO_vfprintf_internal
5.70% find find [.] 0x0000000000351d
3.39% find [kernel] [k] ext4_htree_store_dirent
2.85% find [kernel] [k] __kmalloc
2.14% find [kernel] [k] _raw_spin_lock
2.10% find [kernel] [k] read_hpet
2.10% find [kernel] [k] half_md4_transform
2.08% find libc-2.10.2.so [.] __GI_memmove
[acme@doppio tmp]$ perf report --sort dso
# Samples: 1628008142
#
# Overhead Shared Object
# ........ ...........................
#
74.66% [kernel]
16.74% libc-2.10.2.so
7.59% find
0.72% ld-2.10.2.so
0.29% libpthread-2.10.2.so
[acme@doppio tmp]$ cd ..
[acme@doppio linux-2.6-tip]$ uname -r
2.6.33-rc3-tip+
[acme@doppio linux-2.6-tip]$ git branch | grep ^\*
* perf
[acme@doppio linux-2.6-tip]$ cat .git/refs/heads/perf
1dcff0bf19619e4d7bc61628770e6d88c631015c
[acme@doppio linux-2.6-tip]$
- Arnaldo
Arnaldo Carvalho de Melo <[email protected]> writes:
>> Next I updated to the latest linus tree (c5974b835a), and recompiled perf.
>> It still seems to work, and has obviously had a lot of features added, but
>> now it only wants to let me run "perf record" if I'm root.
>
> Don't recall noticing such problem, here it works just fine:
>
> [acme@doppio linux-2.6-tip]$ mkdir tmp
> [acme@doppio linux-2.6-tip]$ cd tmp
> [acme@doppio tmp]$ time perf record find ~/git/ > /dev/null
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.053 MB perf.data (~2312 samples) ]
Weird... if I try your recipe, I get:
$ cd /usr/local/tmp
$ ls
gstlfilt.zip q2.jpg q3.jpg
$ time perf record find /usr/local/src/git/ > /dev/null
Fatal: Permission error - are you root?
real 0m0.032s
user 0m0.004s
sys 0m0.012s
> [acme@doppio linux-2.6-tip]$ uname -r
> 2.6.33-rc3-tip+
Perhaps the newer version of perf works better with newer kernels, or
with some specific option enabled? [Since it's a fairly new tool, I
suppose it may not work well unless the perf version and the kernel
version are in sync.]
I'm using a standard debian kernel:
$ uname -r
2.6.32-trunk-amd64
$ grep PERF_ /boot/config-2.6.32-trunk-amd64
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
I notice that the system call which results in an error for me changed
between the two versions of perf -- from "sys_perf_counter_open" to
"sys_perf_event_open" -- though I don't understand the difference.
Thanks,
-Miles
--
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.
On Thu, 2010-01-07 at 11:49 +0900, Miles Bader wrote:
> Perhaps the newer version of perf works better with newer kernels
Yup. Bisects back to 60ab271617cec607380099f3ed8e84916e48323b. If
running latest kernel, normal user can record fine. Running 31 or 32
kernel with latest perf though, I see the same permission error. Not
immediately obvious to me why reverting this commit does indeed fix it.
commit 60ab271617cec607380099f3ed8e84916e48323b
Author: Peter Zijlstra <[email protected]>
Date: Wed Dec 16 17:55:56 2009 +0100
perf record: Use per-task-per-cpu events for inherited events
Create events with a pid and cpu contraint for inherited events
so that we get a stream per cpu, instead of all cpus contending
on a single stream.
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: [email protected]
Cc: Paul Mackerras <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 9b7c6d8..63136d0 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -278,7 +278,7 @@ static void create_counter(int counter, int cpu, pid_t pid)
attr->mmap = track;
attr->comm = track;
- attr->inherit = (cpu < 0) && inherit;
+ attr->inherit = inherit;
attr->disabled = 1;
try_again:
@@ -537,7 +537,7 @@ static int __cmd_record(int argc __used, const char **argv)
}
- if (!system_wide || profile_cpu != -1) {
+ if ((!system_wide && !inherit) || profile_cpu != -1) {
open_counters(profile_cpu, target_pid);
} else {
for (i = 0; i < nr_cpus; i++)
On Thu, 2010-01-07 at 05:48 +0100, Mike Galbraith wrote:
> On Thu, 2010-01-07 at 11:49 +0900, Miles Bader wrote:
>
> > Perhaps the newer version of perf works better with newer kernels
>
> Yup. Bisects back to 60ab271617cec607380099f3ed8e84916e48323b. If
> running latest kernel, normal user can record fine. Running 31 or 32
> kernel with latest perf though, I see the same permission error. Not
> immediately obvious to me why reverting this commit does indeed fix it.
Heh. echo 0 > /proc/sys/kernel/perf_event_paranoid :)
-Mike
On Thu, 2010-01-07 at 05:48 +0100, Mike Galbraith wrote:
> On Thu, 2010-01-07 at 11:49 +0900, Miles Bader wrote:
>
> > Perhaps the newer version of perf works better with newer kernels
>
> Yup. Bisects back to 60ab271617cec607380099f3ed8e84916e48323b. If
> running latest kernel, normal user can record fine. Running 31 or 32
> kernel with latest perf though, I see the same permission error. Not
> immediately obvious to me why reverting this commit does indeed fix it.
That commit will do something the old perf doesn't support and will fail
to create the counters.