On Monday 01 July 2002 10:48 pm, Tom Rini wrote:
> On Tue, Jul 02, 2002 at 01:44:32AM +0200, J.A. Magallon wrote:
> > On 2002.07.01 Tom Rini wrote:
> > >On Mon, Jul 01, 2002 at 01:52:54PM -0400, Bill Davidsen wrote:
> > >> What's the issue?
> > >
> > >b) 2.4 is the _stable_ tree. If every big change in 2.5 got back ported
> > >to 2.4, it'd be just like 2.5 :)
> >
> > So you want to wait till 2.6.40 to be able to use a O1 scheduler on a
> > kernel that does not eat up your drives ? (say, next year by this same
> > month...)
>
> I assume you mean 2.4.60 here, and no, I don't think O1 scheduler should
> go into 2.4 ever. We're aiming for a _stable_ series here. Let me
Ah, monday morning virtue, overcompensating for 2.4.10. It's the hangover
speaking...
"We upgrade our kernel on a production machine without testing it first, and
we get mad if anything actually CHANGED. We want that upgrade to be a NOP,
darn it! We want it to be as if we never did it in the first place, that's
why we do it..."
If you want stone tablet stability, why the heck are you upgrading your
kernel? Downloading the new version off of kernel.org generally means you're
mucking about with a working box, making changes that are not 100% required.
If a security vulnerability comes out, you have the source and can patch the
specific bug in your version. (If you're not up to that, you're probably
using a vendor kernel, which is a whole 'nother can of worms.)
If you install new hardware or software, and it going "boing" would be a bad
thing, you try it on a scratch box first. If you don't, you deserve what you
get.
I'm under the impression 2.4.19 is introducing chunks of Andre Hedrick's new
IDE code. So it's ok to upgrade something that can, in case of a bug, eat
your data silently in a way that journaling won't detect. Why? LBA-48 and
ATA-133, of course. But scheduling, which is SUPPOSED to be
non-deterministic from day one and could theoretically be brain-dead round
robin without affecting anything but performance... That's not safe to
upgrade. Right.
If you have a race condition in your code that a new scheduler triggers,
ANYTHING could trigger it. 2.4.18 behaves horribly under load, try md5sum on
an iso image and then pull up an xterm and su to another user. It can take
30 seconds. (Yeah, that's mostly IO starvation rather than the scheduler,
but still, how is the new scheduler going to do WORSE than this?)
The argument here is basically "don't change anything". It's not exactly a
series then, is it? If you want trailing edge, 2.0 is still being
maintained, let alone 2.2. Those have a great excuse for not accepting
anything new beyond a really obvious bugfix. 2.4 does not, because 2.6 isn't
out yet. Backporting of somethings from 2.5 to 2.4 will occur until then,
and O(1) is an obvious eventual candidate.
> stress that again, _stable_. I'd hope that 2.4.60 is as slow in coming
> as 2.0.40 is.
So the fact that it's in Alan Cox's kernel (meaning Red Hat is shipping it in
2.4.18-5.55, meaning that if more people aren't actually USING it yet than
marcelo's 2.4, they will be soon), and andrea's kernel (meaning new VM
development is being done with it in mind)... It may not be "sufficiently
tested" yet but it's GETTING a lot of testing. You use anything EXCEPT a
stock vanilla 2.4, you're probably getting O(1) at this point.
If the vendors are starting to ship the thing already, what is the DOWN side
to integrating it? The down side to NEVER integrating it is eventually fewer
people using the kernel off of kernel.org.
Does this remind anybody else of the 0.90 software raid stuff? At some point
it makes more sense to keep the OLD one around as a patch for the 5% of the
community that doesn't want to upgrade. We're not there on the scheduler
yet, but "should not happen" without a qualifier means "never"...
> > >c) I also suspect that it hasn't been as widley tested on !x86 as the
> > >stuff currently in 2.4. And again, 2.4 is the stable tree.
> >
> > I know it is not a priority for 2.4, but say it wil never happen...
>
> I won't say it will never happen, just that I don't think it should.
> It's a rather invasive thing (and as Ingo said, it's just not getting
> stable).
Ingo's main objection was that the patch is only 6 months old, and that 2.4
is only now stabilizing and that bug squeezing and smoothing should be given
a little longer to ensure that people have the option of NOT upgrading, and
that those upgrading want improvements rather than critical "this just
doesn't work" fixes. And that's a fine argument.
But 2.6 isn't going to be out this year. It's not even having its first
freeze until October. Traditionally, we've been running a year and a half
between stable releases (and another six months to actually get the new one
battle-tested to where the distros and at least 50% of the production boxes
upgrade.) We've got a year to eighteen months left on that cycle. Are the
distros going to hold off adding it to 2.4 for a year to 18 months?
The real question is, how much MORE conservative than the distros should the
mainline kernels be?
Rob
-
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/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:10 EST