lkml.org 
[lkml]   [2007]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: CFS review
From
Date
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]
\
 
 \ /
  Last update: 2007-08-29 10:01    [W:0.120 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site