[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070828080218.GA12247@elte.hu>
Date: Tue, 28 Aug 2007 10:02:18 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Xavier Bestel <xavier.bestel@...e.fr>
Cc: Al Boldi <a1426z@...ab.com>, Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: CFS review
* Xavier Bestel <xavier.bestel@...e.fr> wrote:
> Are you sure they are stalled ? What you may have is simple gears
> running at a multiple of your screen refresh rate, so they only appear
> stalled.
>
> Plus, as said Linus, you're not really testing the kernel scheduler.
> gears is really bad benchmark, it should die.
i like glxgears as long as it runs on _real_ 3D hardware, because there
it has minimal interaction with X and so it's an excellent visual test
about consistency of scheduling. You can immediately see (literally)
scheduling hickups down to a millisecond range (!). In this sense, if
done and interpreted carefully, glxgears gives more feedback than many
audio tests. (audio latency problems are audible, but on most sound hw
it takes quite a bit of latency to produce an xrun.) So basically
glxgears is the "early warning system" that tells us about the potential
for xruns earlier than an xrun would happen for real.
[ of course you can also run all the other tools to get numeric results,
but glxgears is nice in that it gives immediate visual feedback. ]
but i agree that on a non-accelerated X setup glxgears is not really
meaningful. It can have similar "spam the X server" effects as xperf.
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