Re: CFS review

[Keith Packard]

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@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part