Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4

[Ingo Molnar]

* Mark_H_Johnson@xxxxxxxxxxxx <Mark_H_Johnson@xxxxxxxxxxxx> wrote:

> I am aware of slow responses normally during tests. However the audio
> test should only use one CPU out of two. The other CPU is busy as well
> with a cpu burner (nice 10) but that should leave me CPU cycles to
> move the mouse, swap windows, etc.  The "lock up" I saw this time was
> a lot more severe (no mouse motion for several minutes at a time). I
> knew the system was still running since the audio continued to play.

the way i typically debug such scenarios is to set up a separate
'highprio console' of some sorts. E.g. log in via the network from
another box and make sure all processing of that console is SCHED_FIFO. 
(in the network case that would mean the network IRQ, ksoftirqd, sshd,
login and bash.) Such a 'highprio console' should have a higher priority
than any other task in the system. If you run alot of stuff in it then
it will surely disturb your measurements (and largely invalidate them),
but otherwise it can be useful to have it around just in case you
experience a lockup that you suspect to be some sort of livelock or
starvation. Whenever the lockup happens, check out what's going on, via
the highprio console.

another useful 'highprio console' is the text console itself - in this
case only login and bash has to be chrt-ed, and the runtime impact on
the test is smaller as well. This is only useful if you can start your
'bad' workload over ssh or via networked X.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/