On Tue, 20 Jan 2009, Ingo Molnar wrote: > > * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > On Tue, 20 Jan 2009, Ingo Molnar wrote: > > > Another test would be to build the scheduler latency tracer into your > > > kernel: > > > > > > CONFIG_SCHED_TRACER=y > > > > > > And enable it via: > > > > > > echo wakeup > /debug/tracing/current_tracer > > > > > > and you should be seeing the worst-case scheduling latency traces in > > > /debug/tracing/trace, and the largest observed latency will be in > > > /debug/tracing/tracing_max_latency [in microseconds]. > > > > Note, the wakeup latency only tests realtime threads, since other > > threads can have other issues for wakeup. I could change the wakeup > > tracer as wakeup_rt, and make a new "wakeup" that tests all threads, but > > it may be difficult to get something accurate. > > hm, that's a significant regression then. The latency tracer used to > measure the highest-prio task in the system - be that RT or non-rt. Well, it is a regression from what was in -rt yes. But not from what ever was in mainline. But I needed to change this to detect the problem that we solved with push and pull of rt tasks. The wake up of a non-rt tasks always took longer than an -rt task, and by tracing all tasks, I never got the wake up latency of an rt task. As I mentioned earlier, I can make a wakeup-rt to do the rt tracing, and make wakeup do all tasks. -- Steve -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
