Linux 2.6 Kernel Stability Freeze

An anonymous reader writes "Linux Creator Linus Torvalds released the 2.6.0-test7 Linux development kernel today and declared a "stability freeze". It has been made quite clear that from this point only "strictly necessary stuff" will be accepted, clearing the way for an official 2.6.0 release sooner than later... possibly at the end of this month."

Comments

That's good

[ixt]

2.5 has been largely successful, and a lot of end users were able to compile it. 2.3? That's another story. I remember not being able to compile 2.3 once.

Good job to all the kernel hackers.

This month will certainly go down as

[Maskirovka]

The October of cool new toys:
Sony PSX
Panther (Mac OS 10.3)
2.6 kernal
Half LIfe 2
Ow! Ouch! Sorry!

Re:Features?

[Anonymous Coward]

Oh, I dunno, SCO registration form on the first boot-up?

My Module

[blackmonday]

I wrote a speaker bracelet module. Alas, it's been rejected because I turned it in too late. It was really cool though.

Stability freeze: In related news..

[adeyadey]

..Microsoft, after the latest virus attack, have declared an instability melt..

Reiser 4

[agrippa_cash]

So it looks like we'll have to wait a while longer for Reiser4, or were some of the Reiser4 implimentation problems due to the shifting kernel patches? Anyone? Anyone?

Re:Reiser 4

[caluml]

More importantly, is XFS in there by default? I haven't tried it since about 2.5.59. It's annoying when patches made for vanilla 2.4 don't apply on 2.4 + XFS. If the vanilla kernel came with XFS, those patches would be made against that, and would apply.

Re:Reiser 4

[caluml]

Then the answer is yes. Reiserfs for lots of small files, XFS for lots of big files or its nice ACLs, and ext2 for that /boot partition. Ext3 over my dead slow body.

Re:Reiser 4

[Skeme]

Good question. It will appear in someone's (I believe AA's) tree in a couple months or weeks. From there it will stabilize and get added to 2.6. Here's the latest status update from Hans:

The filesystem is getting reasonably stable.
This weekend we hit a bug in space reservation, which we can't reproduce yet but probably isn't too hard to find by code inspection. There is some thought that the assertion not the space reservation is buggy, in any case we'll release a snapshot after it is fixed.

Our performance is generally wonderful and getting better.
It has the following weakpoints:

* We allocate a "jnode" per unformatted node in the filesystem. The traversing of these jnodes consumes more CPU than performing the memcpy from user space to kernel space when doing large writes. I don't yet really understand on an intuitive level why this is so, which is a reflection on my ignorance as it is consistent with stories I have heard from other implementors of filesystems who found that eliminating per page structures was an important part of optimizing large writes. We will fix this by creating a new structure called an extent-node that will exist on a per extent basis, and this will probably cure the problem. This will greatly simplify parts of our code for reasons I won't go into, and it will also take us 6 weeks to do it. I don't think users should wait for it, and so we will ship without it.

* Our dbench performance was poor, has improved due to coding changes, and we need to test and analyze again. Perhaps more fixes will be needed, we can't say yet.

* Our fsync performance is poor. We will pay attention to this next year, frankly, after we have fully implemented the transactions API. At that point we will say something like, if you care about fsync performance you should be using the transactions API and/or sponsoring us to tune for NVRAM, users will say back "but our legacy apps on hardware without NVRAM matter!", and we will grudgingly but effectively tune for this because we care about real users too.;-)

Nikita recently invented and implemented a clever bit of code that keeps track of the highest node in the tree that spans a directory, and then performs repeat lookups within the same directory starting from there rather than the root. This is a nice answer to those who keep asking me, wouldn't it be faster to have separate trees for each directory? Now I have better answer for them --- nice work Nikita. It also has the nice side effect of reducing spin lock contention on the root node for 4-way SMP.

I am hoping to move my laptop to SuSE 9.0 running reiser4 sometime this week, and I am hoping we will ask for more outside testers to help us find bugs at that time. While I have mentioned only the performance flaws in this email, our overall performance seems to leave little doubt that the filesystem as-is is far better than V3, and even though it will get much faster with another year or so of tuning, if now we are the fastest available on Linux, we should be shipping now (assuming we find no new bugs in the last round of internal testing).

Benchmarks can be found at www.namesys.com/benchmarks.html

As you can see in those benchmarks, in V4 tails IMPROVE performance due to saving IO transfer time. This is a great improvement over V3, and generally speaking V4 stomps all over V3 performance. It also scales better, has plugins, and improves semantics a little bit (big semantic improvements will be in the next major release not V4).
You'll also notice that we increased the size of the fileset to be more fair to ext3, and we tested some ext3 configurations Andrew Morton suggested testing.

--
Hans

Not "possibly at the end of this month"

[JoeBuck]

Linus wrote: In other words, this should calm things down so that by the end of October we can look at the state of 2.6.0 without having a lot of noise from 'not strictly necessary' stuff."

That is, at the end of October he will "look at the state of 2.6.0". That's quite different from shipping it.

Who cares.

[BoomerSooner]

Mac OS is on 10.3, that's like 7.7 better. And no fair skipping like MS does. Windows 95 my ass, more like Windows 3.11b

Re:Time to upgrade!

[RealAlaskan]

Great! That means it's really stable now.

BZZZZZZZZZT! WRONG! It's a "stability freeze". That means that the stabilizers are frozen, and can't function. So, it will be unstable until they get the stabilizers repaired.

Sheesh. Goofy kids these days...

Stability?

[Wooky_linuxer]

When the 2.4 series came out, it was much criticisd for not having anything near the stability of the old 2.2 series (I'd say it haven't catch up yet,but since I use it in a desktop machine 2.2 is not an option)... What can we wait from the brave new world the 2.6 kernel will bring?

Re:Stability?

[efti]

I've been using the 2.5 series since 2.5.66 or so. The main reasons I recommend 2.6 are:

• Greatly improved responsiveness under heavy load -- I no longer notice cpu-intensive tasks like a kernel recompile or the slocate database rebuild cron-job happening in the background. And X isn't even running with higher priority.
• Built-in ALSA (Advanced Linux Sound Architecture) -- much improved audio, especially audio recording
• Improved ACPI power management and CPU frequency scaling (my main machine is a laptop)
• Software suspend (just like hybernate on Windows), again handy for laptop users, or those who like to sleep without listening to the whine of their super mega cooler CPU fan / vacuum cleaner attachment.
• Built-in IPSEC support. This is mostly useful for those who need to set up VPN tunnels. I imagine it is more efficient to handle IPSEC inside the TCP/IP stack itself

These are the ones I can think of off the top of my head. I haven't used the built-in IPSEC yet, and software suspend still doesn't work properly on my laptop, but it's not far off. 2.6 will be a pretty sweet series.

Re:Can you help me reinstall iLife on my iBook?

[Gherald]

Do the internet a favor and click the "Shutdown" icon.

In pratice

[rf0]

I've been using 2.6.0-test4-mm4 daily without problems. No glitches. The 2.6.0 kernel has real improvments in the shape of Alsa being mainstream. Also the I/O schedular + interactivity is much better under load than the 2.4 kernel.

Of course however I won't be putting 2.6 into production use until at least 2.6.8 or there abouts to make sure there are no nasty surprises in there

Rus

Modular source code?

[pjack76]

How difficult is it to only download those kernel modules I actually want to compile? As time goes on and new stuff keeps getting added to the kernel the source just gets out of hand. Someone should set up a little webby clicky thing that's like "make menuconfig" but then assembles a tarball only containing your precise configuration and those modules you've selected. Just a thought.

Strictly necessary stuff?

[bennomatic]

Wait! Wait! Wait! I've got a million lines of SCO code I want to insert!

Re:Strictly necessary stuff?

[GlynDavies]

Bad luck, looks like your too late. Still, try contacting IBM or RedHat - they may have some alternative suggestions on where to insert it. ;-)

I miss 'make dep'

[Theatetus]

It's not the same thing without 'make dep && make clean bzImage modules modules_install'

Now it's just 'make menuconfig && make'

Linux has gotten soft... time to migrate to BSD. I would if I could get my laptop's touchpad to work. Sigh...