On Tue, 2003-08-05 at 12:45, Con Kolivas wrote:
> On Tue, 5 Aug 2003 20:32, Nick Piggin wrote:
> > What you are doing is restricting some range so it can adapt more quickly
> > right? So you still have the problem in the cases where you are not
> > restricting this range.
> 
> Avoiding it becoming interactive in the first place is the answer. Anything 
> more rapid and X dies dead as soon as you start moving a window for example, 
> and new apps are seen as cpu hogs during startup and will take _forever_ to 
> start under load. It's a tricky juggling act and I keep throwing more balls 
> at it.

generally that's a sign that the approach might not be the best one.

Lets face it: we're trying to estimate behavior here. Result: There
ALWAYS will be mistakes in that estimator. The more complex the
estimator the fewer such cases you will have, but the more mis-estimated
such cases will be.
The only way to really deal with estimators is to *ALSO* make the price
you pay on mis-estimation acceptable. For the scheduler that most likely
means that you can't punish as hard as we do now, nor give bonuses as
much as we do now.