Cc: Ingo Molnar <mingo@...>, Mike Galbraith <efault@...>, linux kernel mailing list <linux-kernel@...>, ck list <ck@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>
On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
Con,
I think what we're discovering is that a "fair scheduler" is
not going to cut it. After all, running X and ripping CD's and MP3
encoding them is not exactly an esoteric use case. And like it or
not, "nice" defaults to 4.
I suspect Mike is right; the only way to deal with this
regression is some scheduler hints from the desktop subsystem (i.e., X
and friends). Yes, X is broken, it's horrible, yadda, yadda, yadda.
It's also what everyone is using, and it's a fact of life. Just like
we occasionally have had to work around ISA braindamage, and x86
architecture braindamage, and ACPI braindamage all inflicted on us by
Intel. This is just life, and sometimes the clean, elegant solution
is not enough.
Regards,
- Ted
P.S. The other solution that might perhaps work is that we need to
change the meaning of what the nice value does. If we consider "nice"
to be the scheduler hint (from the other direction), then maybe any
niced process should only run a very tiny amount if there are any
non-nice processes ready to run, and that the relative nice values are
used when two niced processes are competing for the CPU.....
-
