sudo perf top shows "Events: 0 cycles".
sudo perf record -ag sleep 10 shows
[ perf record: Woken up 1 time to write data ]
[ perf record: Captured and wrote 0.154 MB perf.data (~6725 samples) ]
However, sudo perf report shows "The perf.data file has no samples!". Also I checked the perf.data recorded and confirmed there is no any samples in it.
The system is "3.2.0-86-virtual #123-Ubuntu SMP Sun Jun 14 18:25:12 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux".
perf version 3.2.69
Inputs are appreciated.
There may be no real samples on idle virtualized system (your linux kernel version has "-virtual" suffix); or there may be no access to hardware counters (-e cycles), which are used by default.
Try to profile some real application like
echo '2^2345678%2'| sudo perf record /usr/bin/bc
Also check software counters like -e cpu-clock:
echo '2^2345678%2'| sudo perf record -e cpu-clock /usr/bin/bc
You may try perf stat (perf stat -d) with same example to find which basic counters are really incremented in your system:
echo '2^2345678%2'| sudo perf stat /usr/bin/bc
About "(~6725 samples)" output - perf record doesn't not count samples in its output, it just estimates their count but this estimation is always wrong. There is some fixed part of any perf.data file without any sample, it may use tens of kb in system-wide mode; and estimation incorrectly counts this part as containing some events of mean length.
Related
I have question related to this one.
I want to (programatically) measure L3 Hits (Accesses) and Misses on an AMD EPYC 7742 CPU (Zen2). I run Linux Kernel 5.4.0-66-generic on Ubuntu Server 20.04.2 LTS. According to the question linked above, the events rFF04 (L3LookupState) and r0106 (L3CombClstrState) should represent the L3 accesses and misses, respectively. Furthermore, Kernel 5.4 should support these events.
However, when measuring it with perf, I run into issues. Similar to the question linked above, if I run numactl -C 0 -m 0 perf stat -e instructions,cycles,r0106,rFF04 ./benchmark, I only measure 0 values. If I try to use numactl -C 0 -m 0 perf stat -e instructions,cycles,amd_l3/r8001/,amd_l3/r0106/, perf complains about "unknown terms". If I use the perf event names, i.e. numactl -C 0 -m 0 perf stat -e instructions,cycles,l3_request_g1.caching_l3_cache_accesses, l3_comb_clstr_state.request_miss perf outputs <not supported> for these events.
Furthermore, I actually want to measure this using perf's C API. Currently, I dispatch a perf_event_attr with type PERF_TYPE_RAW and config set to, e.g., 0x8001. How do I get the amd_l3 PMU stuff into my perf_event_attr object? Otherwise, it would be equivalent to numactl -C 0 -m 0 perf stat -e instructions,cycles,r0106,rFF04 ./benchmark, which is measuring undefined values.
Thank you so much for your help.
I have an application which is running unusually slow. I have reason to suspect that this may be because some specific files are slower to read from and stat.
I know I can use strace to get timing information, but I'd prefer to use perf because the overhead is so much lower.
Brendan Gregg has some helpful examples of using perf:
http://www.brendangregg.com/perf.html
But his first system call example only shows aggregate timings across all calls and I need per-file timings. His second system call example doesn't include timings, and only shows fd numbers, not real paths.
How do I piece this together? I'm looking to get something similar to what I would get from “strace -Tttt -e trace=file”.
Added bonus would be if I can measure cycles at the same time.
Output from strace -Tttt -e trace=file is trace (tracing tool), and perf is usually used as profiling tool (aggregating time spent in function by name - in perf record by default on time or on hardware events + perf report, perf top modes) or as statistics tool (in perf stat mode - with counting of some events over all running time of the program).
You should try some tracing tool (trace-cmd, sysdig, lttng, ...) or you can try to use perf in tracing modes (perf record with tracepoints and perf script to output non-aggregated log over time)
There are tracepoints for syscalls (syscalls 614):
http://www.brendangregg.com/perf.html#Tracepoints
http://www.brendangregg.com/perf.html#StaticKernelTracing
perf record -e 'syscalls:sys_*' ./program
perf script
Example of output with format: process_name, pid, [cpu_core], time_since_boot_seconds.microseconds:, tracepoint_name, tracepoint_arguments
ls 19178 [001] 16529.466566: syscalls:sys_enter_open: filename: 0x7f6ae4c38f82, flags: 0x00080000, mode: 0x
ls 19178 [001] 16529.466570: syscalls:sys_exit_open: 0x4
ls 19178 [001] 16529.466570: syscalls:sys_enter_newfstat: fd: 0x00000004, statbuf: 0x7ffe22df92f0
ls 19178 [001] 16529.466572: syscalls:sys_exit_newfstat: 0x0
ls 19178 [001] 16529.466573: syscalls:sys_enter_mmap: addr: 0x00000000, len: 0x00042e6f, prot: 0x00000001,
ls 19178 [001] 16529.466767: syscalls:sys_exit_mmap: 0x7f6ae4df8000
ls 19178 [001] 16529.466768: syscalls:sys_enter_close: fd: 0x00000004
ls 19178 [001] 16529.466769: syscalls:sys_exit_close: 0x0
You may also try perf record -g -e 'syscalls:sys_*' to record function backtrace (to get information which function of the application did the syscall, and who did call this function; works better with debug information).
perf as tracing tool may not decode syscall (tracepoint) arguments; and tracing tools like trace-cmd or lttng may decode them better (at least decoding file name in open syscall).
When I use perf to collect system stats, like this
sudo perf record -a -g -F 997 -p pid sleep 30
then I got
Error:
You may not have permission to collect stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid:
-1 - Not paranoid at all
0 - Disallow raw tracepoint access for unpriv
1 - Disallow cpu events for unpriv
2 - Disallow kernel profiling for unpriv
I have no permission to modify /proc/sys/kernel/perf_event_paranoid, even in root.
I try to add "kernal.perf_event_paranoid=-1" into /etc/sysctl.conf, and use
sysctl -p
to reload params.
Again I have no permission to load param kernal.perf_event_paranoid.
How can I use perf to collect stats?
My mother tongue is not English, sorry for my English.
I use pppd with a GPRS module.
I use like pppd record record.pcap call tdscdma command to access Internet.And pppdump record.pcap or wireshark to show the record.pcap.
when pppd run ,the record.pcap will save all data and the file size getting bigger and bigger.
Now I am just want save last(Newest) 1Mb(for example,or quantity) message.And how can I limit the file size.
I am more concerned about the recent network conditions. FIFO is not necessary.if the file bigger than 1Mb, truncate it to zero is OK too.
[root#AT91SAM9-RT9x5 logs]# pppd -v
pppd: unrecognized option '-v'
pppd version 2.4.5
[root#AT91SAM9-RT9x5 logs]# uname -a
Linux AT91SAM9-RT9x5 2.6.39 #34 Wed Jun 4 16:12:41 CST 2014 armv5tejl GNU/Linux
Use wireshark looks like this:
Can you use tcpdump program for capturing traffic of ppp0 interface?
There are -C and -W options for limiting size of output files.
Example:
tcpdump -i ppp0 -C 1 -W 2 -w file.pcap
See more from man page: tcpdump(8).
I am trying to get a list of available frequencies for my cpu using the cpupower tool.
I am executing following command-
cpupower -c 0,1,4,5 frequency-info
This gives me much information but I need to see a list of available frequencies to which I can set these CPUs to.
On older versions of Fedora, I used to do this
$ cat /system/cpu/cpu3/cpufreq/scaling_available_frequencies
2201000 2200000 2100000 2000000 1800000 1700000 1600000 1500000 1300000 1200000 1100000
but on Fedora 20, cpufreq is obsolete. I googled and found that cpupower has same functionality like cpufreq.
How do you use it to get a list of available frequencies?
cpupower frequency-info
should give you your info