On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
> > > > We are getting good interactive response with a fair scheduler yet
> > > > you seem intent on overloading it to find fault with it.
> > >
> > > I'm not trying to find fault, I'm TESTING AND REPORTING. Was.
> >
> > Con, could you please take Mike's report of this regression seriously
> > and address it? Thanks,
>
> Sure.
>
> Mike the cpu is being proportioned out perfectly according to fairness as I
> mentioned in the prior email, yet X is getting the lower latency scheduling.
> I'm not sure within the bounds of fairness what more would you have happen
> to your liking with this test case?
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.....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
