30

Do I need to have to run perf userspace tool as system administrator (root), or can I run it (or at least some subcommands) as an ordinary user?

Improve this question
4
  • 2
    Unix programs that can't do what they need to do for lack of permissions will usually thrown an error if they can't do their job. Run it and see!
    – Caleb
    Commented Jun 2, 2011 at 10:55
  • 1
    I am asking this question to decide whether it is worth trying to install (as ordinary user, in $HOME) userspace part of perf tool (which is/can be non-trivial).
    – Jakub Narębski
    Commented Jun 2, 2011 at 12:19
  • FYI in Ubuntu perf is in linux-tools package, so installing perf there is simple.
    – Jakub Narębski
    Commented Jun 12, 2013 at 16:59
  • 1
    @JakubNarębski: Except if it is not your own machine and the admins are reluctant to install packages.
    – Martin Ueding
    Commented May 15, 2019 at 12:09

2 Answers 2

Reset to default
42

What you can do with perf without being root depends on the kernel.perf_event_paranoid sysctl setting.

  • kernel.perf_event_paranoid = 2: you can't take any measurements. The perf utility might still be useful to analyse existing records with perf ls, perf report, perf timechart or perf trace.
  • kernel.perf_event_paranoid = 1: you can trace a command with perf stat or perf record, and get kernel profiling data.
  • kernel.perf_event_paranoid = 0: you can trace a command with perf stat or perf record, and get CPU event data.
  • kernel.perf_event_paranoid = -1: you get raw access to kernel tracepoints (specifically, you can mmap the file created by perf_event_open, I don't know what the implications are).
Improve this answer
4
  • 1
    Nice. cat /proc/sys/kernel/perf_event_paranoid returns 1, so it seems that I would be able to take at least some measurements (BTW. whats the difference betwen "kernel profiling data" and "CPU event data"? Reference is enough)
    – Jakub Narębski
    Commented Jun 2, 2011 at 17:48
  • 2
    @Jakub: From what I understand, kernel events let you see calls to various kernel functions. CPU events are counters in the CPU that tell you how many times a particular location in memory was hit. I've never used them, so I can't tell you more about them; LWN has quite a few article on the topic, and it's still evolving.
    – Gilles 'SO- stop being evil'
    Commented Jun 2, 2011 at 18:03
  • 4
    With paranoid=2, you can still profile your own code in user-space (e.g. perf stat awk 'BEGIN{for(i=0;i<10000000;i++){}}' will show accurate user-space cycle and instruction counts, and you can even get counts for uops_issued.any and so on), but you don't get counts for code that ran during system calls/interrupts. So the reported CPU frequency (cycles / time) is at least slightly lower than actual because of time spent in kernel. See also What restriction is perf_event_paranoid == 1 actually putting on x86 perf?
    – Peter Cordes
    Commented Aug 19, 2018 at 20:58
  • "CPU events" means profiling everything on a whole core, instead of per-process / thread. i.e. paranoid=1 or higher stops you from profiling other user's code, and 1 only lets you profile kernel code invoked by your own processes (system calls.)
    – Peter Cordes
    Commented Aug 19, 2018 at 21:00
-1

These are the steps I needed to take to allow perf to record events on RHEL8:

sudo mount -o remount,mode=755 /sys/kernel/tracing/
sudo sh -c 'echo -1 >/proc/sys/kernel/perf_event_paranoid'
sudo sh -c 'echo 0 >/proc/sys/kernel/kptr_restrict'

After that I could run perf as a regular user:

~$ perf record -e block:block_rq_complete -ag sleep 5
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.045 MB perf data ]
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .