Kernel scheduling algorithm and X.Org performance

[Alan Cox]

On Mer, 2005-08-31 at 16:47 +0400, Dmitry Shatrov wrote:
> My guess is that to get the Windows-like picture of operation on X one
> should probably do the following:
> 1) renice Xorg process to -6

This has been tried before and the results were pretty unimpressive for
most users if not horrible. It is rare that X wants to do stuff and is
pre-empted anyway. You can tune a system for your usage but for everyone
elses gets a little hairier.


> X server wakes up immediately, because it is a highest-priority 
> process.

On an idle system it will wake immediately anyway because there is
nothing else to run. Priority doesn't matter.

> 3. X wakes up and reads WM's commands. It says to move a window, so X
> actually moves it, but a part of the window at the background is to be
> repainted. X issues a repaint command to that client. And also it is
> very likely that part of WM's decorations is to be redrawn as well 
> (this
> point confuses me - when does WM actually paint its decorations? 

Up to the WM. It could even mark the decorations as server side buffered
given their small size.

> content is erased. This is what users call "slow". This is why we set
> WM's priority to 1 (the least of the three): this way the client will
> wake up first.

On your specific uniprocessor setup. But the rest of your breakdown is
interesting. What occurs if you teach the window mangler to batch events
when this occurs.

> 4. Now, the client wakes up. It repaints itself, but this is likely to
> take long time (modern desktop programs are quite complicated)

It takes ages because a lot of the apps are badly written, use APIs that
don't accelerate, produce a lot of queries that stall streams of
commands and so have very high latencies in responding to redraws. I've
played with this and many bigger Gnome apps take over ten seconds to
respond to a redraw if they are the slightest bit busy. The windows
people have had time to get their rendering thread model right.

Its also not helped by the X server and EXA hopefully will improve that,
nor by the lack of sneaky tricks like caching the current visible window
top level surfaces as some other window systems do so that moves don't
cause a redraw. This makes total sense on any sane sized machine but
isn't handled by X. It doesn't help resizes of course.

> decoration are subject to be redrawn as well, and (just for an 
> example)
> metacity is quite slow in this. Slow enough to see it visually. The 
> box

Pick a decent theme ;)

> The first is for Xorg's DIX Dispatch() function (it's against
> X11R6.8.1). My point there is that We should give a priority to 
> handling
> client's commands first, and when we're done with that, handle the
> input. I don't base this on some deep research, just an abstract 
> thought

That means a client that goes berserk kills your session as you can
never get input into the system. Add some kind of  heuristic to ensure
noisy clients lose priority after a little bit and it makes interesting
sense.

> My point is that it is time to figure out what scheduling algorithm is
> the best for X.Org and implement it in the Linux kernel. X server and 
> WM

Its unlikely such an algorithm will exist and work for all cases and all
systems. 


It seems to me the big argument here is for window manglers and maybe X
to be smarter about batching events. That isn't helped by the fact X has
no real "window is updated/current". It could be added as a window
property between WM and toolkits that followed the same policy without
having to whack on the X server and would also clean up problems with
things like print to screen.

If you want smooth Mac like handling and have a decent video card/box
then we should be caching the clipped areas of top level windows up to a
certain size in the server.


Alan