[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070829045316.GA15064@elte.hu>
Date: Wed, 29 Aug 2007 06:53:16 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Al Boldi <a1426z@...ab.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Keith Packard <keith.packard@...el.com>
Subject: Re: CFS review
* Al Boldi <a1426z@...ab.com> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists