* 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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
