δΊ 2015/8/29 9:28, Alexei Starovoitov ει: > On 8/27/15 3:42 AM, Kaixu Xia wrote: >> An example is pasted at the bottom of this cover letter. In that example, >> we can get the cpu_cycles and exception taken in sys_write. >> >> $ cat /sys/kernel/debug/tracing/trace_pipe >> $ ./perf record --event perf-bpf.o ls >> ... >> cat-1653 [003] d..1 88174.613854: : ente: CPU-3 >> cyc:48746333 exc:84 >> cat-1653 [003] d..2 88174.613861: : exit: CPU-3 >> cyc:48756041 exc:84 > > nice. probably more complex example that computes the delta of the pmu > counters on the kernel side would be even more interesting.
Right, this is just a little example. Actually, I have tested this ability on kernel side and user space side, that is kprobe and uprobe. The collected delta of the pmu counters form kernel and glibc is correct and meets the expected goals. I will give them in the next version. At this time i wish to get your comment on the current chosen implementation. Now the struct perf_event_map_def is introduced and the user can directly define the struct perf_event_attr, so we can skip the parse_events process and call the sys_perf_event_open on the events directly. This is the most simple implementation, but I am not sure it is the most appropriate. > Do you think you can extend 'perf stat' with a flag that does > stats collection for a given kernel or user function instead of the > whole process ? > Then we can use perf record/report to figure out hot functions and > follow with 'perf stat -f my_hot_func my_process' to drill into > particular function stats. Good idea! I will consider it when this patchset is basically completed. > > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
