Kernel scheduling algorithm and X.Org performance

[Dmitry M. Shatrov]

В Срд, 31/08/2005 в 13:22 -0400, Jim Gettys пишет:
> I believe this is primarily a result how the XAA drivers we currently
> use are implemented.
> 
> They do very stupid things like busy waiting on hardware in user space
> (using cycles gratuitously), and never releasing the CPU for other use.
> 
> The problem with this, beyond burning lots of cycles, is that it
> completely confuses any sane OS scheduler into thinking this is a
> compute bound process, when, if the drivers were kind enough to let the
> CPU do something else until the display hardware is free, would think
> that the X server is a highly interactive process, and give it the
> appropriate scheduling boost.  And on Linux 2.4 systems shipped by many
> commercial Linux vendors, this was further worsened by the sorts of
> scheduler modifications many of those vendor's shipped (Linux 2.6 does
> much better).
> 
> Shall we say, that on previous UNIX systems, where we had kernel driver
> support to enable the user mode drivers to give the CPU back,
> interactive response was *much* better, despite being on much slower
> hardware than today's hardware.  Many of those systems also had more
> sophisticated schedulers; Linux 2.6 is the first Linux system to have a
> decent process scheduler (IMHO).
> 				- Jim

And that's true. I'd like to add that one does not have to go too far to
find a "more interactive" system that runs X. I still remember how
FreeBSD 4.7 felt a lot better than RedHat 7.3 in terms of GNOME and KDE
responsibility. And it may still feel better, I just had no chance to
look at FreeBSD 5.x releases yet. I didn't think about the reasons at
that time and just concluded that BSD code is more mature that Linux,
but now I think that the main reason was a different process scheduler
that occasionally performed better with X Windows.