Scheduler starvation (2.5.x, 2.6.0-test1)

[Simon Kirby <sim@netnation.com>]

I keep seeing cases where browsing in mozilla / galeon will suck away all
CPU from X updating the mouse, xmms playing, etc., for about a second as
Mozilla renders a page (which should take 50 ms to render, but anyway..).

This is only a Celeron 466 MHz, but there never used to be such a problem
in 2.2 and 2.4 kernels.  All processes (X, galeon, xmms) are running with
the default nice of 0.  It seems there is something with the scheduler
heuristics which is giving galeon a way-too-large preemptive timeslice
and not even allowing enough CPU to other processes to, for example, let
X update the mouse cursor.  This seems wrong -- Shouldn't the device
event always wake up and switch to the X task if the process has usable
timeslices left?

This only seems to happen after letting the system settle for some time. 
If I refresh a page once, the problem happens.  Again, less.  Again, the
scheduler seems to allow mouse updates normally.  I have to wait about 30
seconds for the problem to occur again.  This is much easier to see with
X reniced to +1.  It occurs with X reniced to +0, but not as often.  With
the old scheduler, +20 wouldn't even make a noticeable difference because
mouse events would still wake up and run the process as expected.

It is really easy to notice the problem on this box not because of the
audible and visible skips, but the fact that there's a bug in the ALSA
Gravis Ultrasound Classic driver which causes it to sometimes play
incorrect portions of RAM when the sound restarts. :)

Is anybody else seeing this or is it something to do with my setup here?

Simon-