> Uladzislau Rezki <urezki@xxxxxxxxx> wrote:
>
> > <snip>
> > root@pc636:/sys/kernel/debug/tracing# cat set_ftrace_filter
> > measure_schedule_delayed_work.constprop.86
> > root@pc636:/sys/kernel/debug/tracing# cat tracing_thresh
> > 5
> > root@pc636:/sys/kernel/debug/tracing# cat current_tracer
> > function_graph
> > root@pc636:/sys/kernel/debug/tracing#
> > <snip>
> >
> > Also i set 5 microseconds threshold to filter out what is less
> > and added the latency-format trace option.
>
> Ah, I forgot that tracing_thresh affects function graph tracing.
>
> The tracing infrastructure has so many features, I can't even keep up ;-)
>
No problem :)
BTW, i decided to perform manual measurement of the schedule_delayed_work()
duration, just in case:
test PC: laptop with Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
<snip>
static void noinline
measure_schedule_delayed_work(struct kfree_rcu_cpu *krcp)
{
u64 delta;
delta = sched_clock();
schedule_delayed_work(&krcp->monitor_work, KFREE_DRAIN_JIFFIES);
delta = sched_clock() - delta;
if (delta > 100)
trace_printk("-> took %llu nanoseconds.\n", delta);
}
<snip>
I get the following figures of taken time:
MEDIAN: 831 nanoseconds
MAX: 4423 nanoseconds
MIN: 123 nanoseconds
The data you can find here: ftp://vps418301.ovh.net/incoming/measure_schedule_delayed_work.txt
--
Vlad Rezki
