Re: Profiling sleep times?

["avagin@gmail.com" <avagin@gmail.com>]

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