Messages in this thread |  | | | Date | Tue, 20 Jan 2009 12:53:53 -0500 (EST) | | From | Steven Rostedt <> | | Subject | Re: [Bug #12465] KVM guests stalling on 2.6.28 (bisected) |
| |
On Tue, 20 Jan 2009, Ingo Molnar wrote:
> > * Steven Rostedt <rostedt@goodmis.org> 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
|  |