No. He's saying that it used to be OK, but it has got worse.
A much simpler test is to start a big compilation and then madly
waggle an X window around. Goes OK for a few seconds, and then
seizes up quite horridly. Presumably because the scheduler has
suddenly decided that the X server has become a "batch" process
and is scheduling it in a similar manner to the compilation.
If you stop wiggling the window for 5-10 seconds it comes back.
Presumably because the scheduler has decided that the X server is
"interactive" again.
When it happens, it's *very* bad. The mouse cursor doesn't move
for 0.5-1.0 seconds and then takes great leaps. It is unusable.
Strangely it does not happen (much) when the background load is
a few busywaits. It has to be a compilation - maybe short-lived
batch processes is what triggers it.
For me, the X server is sometimes the victim, and the MUA (netscape4)
is frequently victimised. This is because the MUA alternates between
periods of interactivity and periods of compute-intensive work (parsing
large mailboxes). When this problem strikes you have to just sit there
with your arms folded waiting for it to stop.
It needs fixing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/