Kernel scheduling algorithm and X.Org performance

[Dmitry M. Shatrov]

В Срд, 31/08/2005 в 18:23 +0100, 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.

Well, I agree that X priority doesn't really matter. I just altered it
to be sure that nothing weird happens during the experiment.

> > 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.

As an example, metacity seems to defer decorations drawing while kwin does not.
This is probably the result of how GNOME people addressed the problem of
poor window resizing behavior, there is a discussion about this in mail
archives (but I'm not sure it is directly related).
Is it because of Gtk+ merging expose events together or not - doesn't really
matter. At the moment all these client-side optimizations look more like
not-always-clean workarounds of the issue and make it harder to see the
overall picture. As I know, unlike Qt, Gtk+ queues frequent expose events
and lets the application deal with one large expose than a dozen of smaller ones.
It is hard for developers of nontrivial graphics programs to adopt to this
(as it was once hard for me). Did you ever notice how list scrolling lags in
Gtk+, especially when you use a theme with bitmap-tiled background?
(something that does not happen in Qt), or how badly Evince PDF viewer
(at least its earlier versions, I don't have the most recent one)
handles scrolling compared to kpdf? I think all these complications are the
consequence of suboptimal scheduling of WM and X clients, and that has lead to
visual artifacts that are hard to overcome and easy to prove they are features
and not bugs. Of course scheduling is not the corner stone but it is probably
one of them.

> > 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.

Well, I'm far from understanding what EXA really is and see that it is
actively discussed and developed. The only I can say is that if you tell
a random Linux geek that there will be EXA soon in one of X.Org releases
and that it will bring smooth transparent graphics to him, he'll smile
and say 'cool'. But add that it did harm Xgl badly and he'll become
really sad and only good beer and not EXA will help to make him smile
again.

> > 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 ;)

I did. But as I said I can always see background-tiled window
decorations of metacity because of how it defers real drawing or because
of Gtk+ optimizations (whatever). My impression is that kwin is much
more responsive even with a nice-looking theme, say, the default
"plastik".

> > 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.

Now that I'm aware of smart scheduling (thanks to Soeren's reply) in X
and have a paper about it in front of me I see that it is not that
trivial, so it is better to forget about random picking in X event
dispatching code.

> > 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. 

Well, take a look at my suggestion, I'll post it in the reply of my own
message in about 30 minutes. I've spent two days on it and used Linux
Trace Toolkit to prove my point and did some screenshots, so hope it
worths a look.

> 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.

That seems wise, but it is probably too late because we're going to have
XComposite everywhere and all windows will be completely back-buffered
anyway.

> Alan

Regards, Dmitry