Re: [OKS] O(1) scheduler in 2.4

[Bill Davidsen]

On Tue, 2 Jul 2002, Tom Rini wrote:

> Sure there is.  It's called stopping feature creep.  O(1) is a nice
> feature, but so is the bio stuff, the initcall levels, and other things
> in 2.5 as well.  But should we back port all of these to 2.4 as well?

None of the other stuff is (a) a solution for any current problem I've
seen (it NEW capability), or (b) has a functional and widely exposed port
to 2.4 already.

The only other feature which which I'm familiar which even remotely fits
those two characteristics is rmap, and with the VM changes Andrea has made
I certainly don't hit really bad VM behaviour on my machines. On some rmap
is a tad better, but compared to 2.4.16 or so 19-preX-aa is acceptable.
 
> > Stable doesn't mean moribund, we are working Andrea's VM stuff in, and
> > that's a LOT more likely to behave differently on hardware with other word
> > length.
> 
> Being someone who actually works on !x86 hardware all of the time, I'm
> slightly warry of Andrea's VM work as well.  But it's also something
> which has been split into numerous small chunks, so hopefully problems
> will be spotted.
> 
> > Keeping inferior performance for another year and then trying to
> > separate 2.5 other unintended features from any possible scheduler issues
> > seems like a reduction in stability for 2.6.
> 
> It's no more of a reduction in stability than not back porting
> everything else.  And making things stable is why eventually Linus says
> 'enough' and kicks out 2.stable.0-test1.  Anyhow, since this isn't a
> subsystem backport, but part of the core kernel, I would think that you
> could only get limited use out of the testing (I remember reading some
> of the O(1) announcments for 2.4.then-current and reading about small
> bugs that weren't in the 2.5 version).

The current scheduler has one big bug; it gives the processor to the wrong
process under some load conditions to the point where the system appears
hung for seconds (or longer). There are two issues, one is best or
acceptable performance, and one is "best worst-case performance." The O(1)
simply doesn't have or hasn't shown me the jackpot case when load changes
on a machine. To me that justifies O(1). Even if it was not faster than
the current scheduler for normal load, the worst case is what needs a fix.

And as I mentioned to Ingo, I don't feel that way about low-latency or
preempt, even though they help a little they don't really fix anything
broken, and I don't argue for inclusion. The current scheduler does behave
very badly in some cases, and should be fixed now, not in 18 months.

-- 
bill davidsen <[e-mail]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.