* Al Boldi <[EMAIL PROTECTED]> wrote:
> I have narrowed it down a bit to add_wait_runtime.
the scheduler is a red herring here. Could you "strace -ttt -TTT" one of
the glxgears instances (and send us the cfs-debug-info.sh output, with
CONFIG_SCHED_DEBUG=y and CONFIG_SCHEDSTATS=y as requested before) so
that we can have a closer look?
i reproduced something similar and there the stall is caused by 1+
second select() delays on the X client<->server socket. The scheduler
stats agree with that:
se.sleep_max : 2194711437
se.block_max : 0
se.exec_max : 977446
se.wait_max : 1912321
the scheduler itself had a worst-case scheduling delay of 1.9
milliseconds for that glxgears instance (which is perfectly good - in
fact - excellent interactivity) - but the task had a maximum sleep time
of 2.19 seconds. So the 'glitch' was not caused by the scheduler.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
