Even i had some issues in schedule latencies. i tried to use trace-cmd record -e all and kernelshark. What i found was since it is run as a separate process it also need to get scheduled to get the traces and by default it is get scheduled in SCHED_OTHER. This tracing is also affected by the values in /proc/sys/kernel/sched_rt_runtime_us and sched_rt_period_us. So what i understood is for initial measurements kernelshark is a good tool, but to go more deep this is not enough. May be profiling tools like OPROF should be good. I am still exploring this. Regards Ashoka. K On Tue, Apr 30, 2013 at 11:32 PM, Stanislav Meduna <stano@xxxxxxxxxx> wrote: > On 30.04.2013 18:52, Carsten Emde wrote: > >> Sure, record everything (trace-cmd record -e all) and analyze the >> traces. > > Well, the problem is that with record -e all I get 20 ms instead > of 1 ms, so I'd say Mr. Heisenberg laughs at me loudly here ;) > > Thanks for the pointer anyway, I'll try to thoroughly read > the available documentation and come up with some sane set > of filters to start with. > > Thanks > -- > Stano > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
