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.
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:28 EST