Hello Arun,
Andrew: what do you think about generalizing my patch to accept a
command line option(s) to specify which fields to use for the purpose of
computing the histogram?
I have no objection, but I don't think, that we really need that.
Now we have not got a real use case. All events which I've seen have not
more than one parameters, which may be used as weight and for this one
we already have parameter "period".
I already said, that you have trouble with sched_stat_sleed due to some
issues in kernel.
The first issue is that __perf_cout doesn't work and I sent the patch,
which fixes it. ([PATCH] perf: fix counter of ftrace events)
And the second issue is that the trace events are divided on some perf
events and their number is restricted by sysctl_perf_event_sample_rate/HZ.
I don't sure, that we should generate more than one "perf" event on each
"trace" event. I think the better way to use SAMPLE_PERIOD and now I
think in this direction.
If you want to fix the bug with sched_stat_sleep, you need to fix the
second issue. I found workaround for your case:
#./perf record -age sched:sched_stat_sleep --filter="comm == foo" -c
100000 -F 100000 -- ~/foo
# ./perf report
# Events: 5K sched:sched_stat_sleep
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ......
#
99.98% foo [unknown] [k] 0
|
--- schedule
|
|--80.20%-- schedule_hrtimeout_range_clock
| schedule_hrtimeout_range
| poll_schedule_timeout
| do_select
| core_sys_select
| sys_select
| system_call_fastpath
|
--19.80%-- do_nanosleep
hrtimer_nanosleep
sys_nanosleep
system_call_fastpath
For static tracepoints, TP_perf_assign() could act as a hint on which
field to default to.
-Arun
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
