Messages in this thread | | | Subject | Re: CFS review | From | Keith Packard <> | Date | Wed, 29 Aug 2007 00:57:29 -0700 |
| |
On Wed, 2007-08-29 at 06:46 +0200, Ingo Molnar wrote:
> ok, i finally managed to reproduce the "artifact" myself on an older > box. It goes like this: start up X with the vesa driver (or with NoDRI) > to force software rendering. Then start up a couple of glxgears > instances. Those glxgears instances update in a very "chunky", > "stuttering" way - each glxgears instance runs/stops/runs/stops at a > rate of a about once per second, and this was reported to me as a > potential CPU scheduler regression.
Hmm. I can't even run two copies of glxgears on software GL code today; it's broken in every X server I have available. Someone broke it a while ago, but no-one noticed. However, this shouldn't be GLX related as the software rasterizer is no different from any other rendering code.
Testing with my smart-scheduler case (many copies of 'plaid') shows that at least with git master, things are working as designed. When GLX is working again, I'll try that as well.
> at a quick glance this is not a CPU scheduler thing: X uses up 99% of > CPU time, all the glxgears tasks (i needed 8 parallel instances to see > the stallings) are using up the remaining 1% of CPU time. The ordering > of the requests from the glxgears tasks is X's choice - and for a > pathological overload situation like this we cannot blame X at all for > not producing a completely smooth output. (although Xorg could perhaps > try to schedule such requests more smoothly, in a more finegrained way?)
It does. It should switch between clients ever 20ms; that's why X spends so much time asking the kernel for the current time.
Make sure the X server isn't running with the smart scheduler disabled; that will cause precisely the symptoms you're seeing here. In the normal usptream sources, you'd have to use '-dumbSched' as an X server command line option.
The old 'scheduler' would run an entire X client's input buffer dry before looking for requests from another client. Because glxgears requests are small but time consuming, this can cause very long delays between client switching.
-- keith.packard@intel.com [unhandled content-type:application/pgp-signature] | |