Xorg 6.8.1 and SCHED_ULE vs. SCHED_4BSD

[Godwin Stewart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 26 Feb 2005 21:49:00 +0100, Michael Nottebrock
<michaelnottebrock at gmx.net> wrote:

> I've been using that for a long time now, since Xorg 6.8.1 breaks vt-
> switching for me.

Well, I decided to bite the bullet and upgraded to Xorg 6.8.1 anyway. It
didn't break vt-switching for me, thankfully. Other than the core keyboard
driver being "kbd" instead of "Keyboard" now, which threw me off for a
couple of minutes, all went well. It seems to be stable enough. Cross
fingers, touch wood etc.

I also took advantage of the latest cvsup to 5.4-PRE and ensuing recompile
to revert to SCHED_4BSD from SCHED_ULE and PREEMPTION in the kernel. The
difference is staggering.

One of the things I've been doing is to record some of my old cassettes
(you know, those old plastic things with 2 holes and a tape inside :) onto
CD. Applying a FFT filter to 50 minutes of audio takes between 10 and 15
minutes on this machine (P-III/550, 384MB) depending on the complexity of
the filter. During this time, with SCHED_ULE and PREEMTION, the machine is
unusable. It freezes hard for periods of 10-12 seconds and then when it
unfreezes (while doing disk i/o apparently) the keys you typed turn up in
the wrong order.

However, now that I've reverted to SCHED_4BSD, the machine remains
perfectly snappy while performing the FFT filter, which doesn't happen
perceptibly slower.

It could be that I misread things entirely (wouldn't be the first time),
but wasn't SCHED_ULE's purpose to *improve* the responsiveness of the
machine when under load? The results I'm getting here are, errmm...
slightly different... Old hardware maybe?

- -- 
G. Stewart - gstewart at bonivet.net

"A reputation for releasing inferior software will make it more
 difficult for a software vendor to induce customers to pay for
 new products or new versions of existing products."
              -- Microsoft
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iD8DBQFCIi9HK5oiGLo9AcYRAonRAJ44xp1VMmCnqIrXoT7w6YtJaF41jACfdv4I
3Sm1JrNWEMnJ0C5wUaywfaY=
=MAkC
-----END PGP SIGNATURE-----