[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708272153530.25853@woody.linux-foundation.org>
Date: Mon, 27 Aug 2007 22:05:37 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Boldi <a1426z@...ab.com>
cc: Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: CFS review
On Tue, 28 Aug 2007, Al Boldi wrote:
>
> No need for framebuffer. All you need is X using the X.org vesa-driver.
> Then start gears like this:
>
> # gears & gears & gears &
>
> Then lay them out side by side to see the periodic stallings for ~10sec.
I don't think this is a good test.
Why?
If you're not using direct rendering, what you have is the X server doing
all the rendering, which in turn means that what you are testing is quite
possibly not so much about the *kernel* scheduling, but about *X-server*
scheduling!
I'm sure the kernel scheduler has an impact, but what's more likely to be
going on is that you're seeing effects that are indirect, and not
necessarily at all even "good".
For example, if the X server is the scheduling point, it's entirely
possible that it ends up showing effects that are more due to the queueing
of the X command stream than due to the scheduler - and that those
stalls are simply due to *that*.
One thing to try is to run the X connection in synchronous mode, which
minimizes queueing issues. I don't know if gears has a flag to turn on
synchronous X messaging, though. Many X programs take the "[+-]sync" flag
to turn on synchronous mode, iirc.
Linus
-
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