23

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?

  • 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 Jun 2 '11 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 Jun 2 '11 at 12:19
  • FYI in Ubuntu perf is in linux-tools package, so installing perf there is simple. – Jakub Narębski Jun 12 '13 at 16:59
  • @JakubNarębski: Except if it is not your own machine and the admins are reluctant to install packages. – Martin Ueding May 15 at 12:09
31

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).
  • 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 Jun 2 '11 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 Jun 2 '11 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 Aug 19 '18 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 Aug 19 '18 at 21:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.