On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
quoted text
> David Schwartz wrote:
> Hm, well.  The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do well.  But
> the impression I'm getting here is that you often get sucky behaviours
> without tuning.

Well, you get strict behaviors as expected for this scheduler. 

quoted text
> > I think it's completely irrational to ask for a scheduler that automatically
> > gives more CPU time to CPU hogs.
> >   
> 
> Well, it doesn't have to.  It could give good low latency with short
> timeslices to things which appear to be interactive.  If the interactive
> program doesn't make good use of its low latency, then it will suck. 
> But that's largely independent of how much overall CPU you give it.

This is way beyond what SCHED_OTHER should do. It can't predict the universe.
Much of the interactivity estimator borders on magic. It just happens to
also "be a good fit" for hacky apps as well almost by accident.

quoted text
> > I agree. I'm not claiming to have the perfect solution. Let's not let the
> > perfect be the enemy of the good though.
> 
> For all its faults, the current scheduler mostly does a good job without
> much tuning - I normally only use "nice" to run cpu-bound things without
> jacking the cpu speed up.  Certainly in my normal interactive use of
> compiz vs make -j4 on a dual-core generally gets pretty pretty good
> results.  I plan on testing the new scheduler soon though.

We can do MUCH better in the long run with something like Con's scheduler.
His approach shouldn't be dismissed because it's running into a relatively
few minor snags large the fault of scheduleing opaque applications. It's
precise enough that it can also be loosened up a bit with additional
control terms (previous email).

It might be good to think about that a bit to see if a schema like this can
be made more adaptable for the environment it serves. You'd then have both
precisely bounded control over CPU usage and enough flexibility for burstly
needs of certain apps.

bill

-
unsubscribe notice
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/