Reiserfs inclusion in 2.4.1 was basically the plan for the very beginning: it was so widely known that it was even reported in the press, so I didn't even bother to point out reiserfs as a 2.4.1 patch.

That said, I wanted to leave the window open for any showstopper bugs, and have a pure "bug-fixes only" 2.4.1 if needed. I'm actually fairly happy that there haven't been any really serious reports so far.

Inclusion of reiserfs is not going to add any bugs for the non-reiserfs case (apart from a stupid merge issue, and now I've watched all the non-reiserfs diffs with a microscope), so in that sense it's safe. Peopel who would have used reiserfs anyway would have gotten more problem reports, so..

If I were you, I'd worry more about the blk-patches from Jens, but they've been around for a long time, and Alan also put them in his tree. Which makes them as safe as any patch we've seen. So I took the approach that "we'll obviously have to put this _somewhere_ in 2.4.x". But that is, at least to me, a potentially bigger worry than reiserfs.

(Actually I'm not so much worried that the blk patches themselves would have bugs, as worried about them showing bugs in block drivers by being better at merging requests. Those kinds of bugs we'll have to figure out during 2.4.x anyway though, but it's a case of a latent bug maybe showing up more easily under higher load generated by the blk fixes).

ResierFS really is a fairly special case: it's been one of the main filesystems at SuSE for a longish time, and of the journalling filesystems it's the only one I know of that is in major real production use already, and has been for some time.

There's no question that there are other Journalling filesystems on the horizon, but I'm not hearing anybody who can't do the patching themselves who is interested in using it. Remember: one of the main criteria for 2.4.x inclusion was the "vendor would want it" part. If it's a "developers might want to play with it" kind of thing, then it might as well live as an external patch for a while.

For that reason, I would expect Ext3 to be the next filesystem to be integrated, but I would _also_ expect that RedHat will actually integrate it into their kernel _first_, and expect me to integrate it into the standard kernel only afterwards.

But no, vendors aren't everything. And there are other vendors than just SuSE and RedHat. So take all of the above with a pinch of salt. And remember: these are just the 2.4.x rules - it's a different game when the development kernel opens again, and "vendor wishes" are much less of an issue when that happens. In the meantime, I see the stable kernel mainly as a way to support vendors, and am thus always weighing things from that angle when worrying about 2.4.x features.

I'd prefer just documenting it and keeping it. I'd hate to have two fairly different modes of behaviour. It's always been the suggested "twice the amount of RAM", although there's historically been the "Linux doesn't really need that much" that we just killed with 2.4.x.

If you have 512MB of RAM, you can probably afford another 40GB or so of harddisk. They are disgustingly cheap these days.

I personally think 2.4.x is going to be as fast or faster at just about anything. We do have some MM issues still to hash out, and tuning to do, but I'm absolutely convinced that 2.4.x is going to be a _lot_ easier to tune than 2.2.x ever was. The "scan the page tables without doing any IO" thing just makes the 2.4.x memory management several orders of magnitude more flexible than 2.2.x ever was.

(This is why I worked so hard at getting the PageDirty semantics right in the last two months or so - and why I released 2.4.0 when I did. Getting PageDirty right was the big step to make all of the VM stuff possible in the first place. Even if it probably looked a bit foolhardy to change the semantics of "writepage()" quite radically just before 2.4 was released).

If you don't have any swap, or if you run out of swap, the major difference between 2.2.x and 2.4.x is probably going to be the oom handling: I suspect that 2.4.x might be more likely to kill things off sooner (but it tries to be graceful about which processes to kill).

Not having any swap is going to be a performance issue for both 2.2.x and 2.4.x - Linux likes to push inactive dirty pages out to swap where they can lie around without bothering anybody, even if there is no _major_ memory crunch going on.

If you do have swap, but it's smaller than your available physical RAM, I suspect that the Linux-2.4 swap pre-allocate may cause that kind of performance degradation earlier than 2.2.x would have. Another way of putting this: in 2.2.x you could use a fairly small swap partition to pick up some of the slack, and in 2.4.x a really small swap-partition doesn't really buy you much anything.

Hold on. First you go and blacklist the entire country of Brazil, then you actually wonder *why* someone working for a Brazilian company might blacklist you in return? The mind boggles.

Dude, I'm all for freedom-of-blacklisting (it is, after all, *your* mailbox), but you gotta take the consequences!

No, John, it's quite obvious that it's _you_ who does not understand. You've saved yourself some spam and pissed off a good deal of the kernel list, including the ones who are in the best position to help you. Was it a good trade?

When so many clueful folks disagree with you, perhaps you should re-examine your actions and ask yourself if they are all wrong, and you know better than all of them, or the inverse.

Many disagree, but many here also support ORBS which does some pretty hefty galaxy wide blacklisting. Some of those that support it are some of the powers that be in here. I.e. clueful folk.

So you can't fault John for personally effecting a policy similar to what ORBS does en masse.

It's a vicious circle but nobody wants to take the effort to figure out a way we can all talk in spite of the filtering. For example, none of the networks I have permit open relaying and all of them are tested and listed "OK" w/ ORBS, but the only way I can email Alan is to post it here or go use somebody else's network. We, the internet, route around brokenness. For some things I arranged relays through their network so I could reach my recipients. What can you do? Spend connection fee after connection fee for a new provider because the provider you were with [which has a strong anti-spam TOS] get's targetted by ORBS? I don't think so.

Yes, it's an aggravation and it isn't going to get any better until enough people get blacklisted. It doesn't matter how good you, your network, or your upstream is, as long as there are projects out there that don't care if they smite 15% good guys as long as they are getting 85% bad guys and there's nothing reasonable you can do. I don't consider switching providers every few months reasonable, especially when given providers are very anti spam in the first place.

it came up ok, except that memory detection is off by a MB. (to be fixed in 2.4.1 or boot with mem= argument in 2.4.0)

What might be important here is your gcc & binutils (as/gas) version, combined with a miscompile in something like __verify_write that doesn't get used on anything but 386 (and hence went undetected).

Only thing strange on my box is that the kernel is compiled with gcc-2.7.2 which is officially unsupported but can be managed if you know what the gcc bugs are.

I finally found the reason why 386es have trouble booting the 2.4.0 kernel:

In routine pagetable_init() in arch/i386/mm/init.c, a pte gets installed before it actually has been filled with valid entries. This causes the kernel text segment to be temporarily unmapped. Pentiums are only lucky to not crash because they have a bigger TLB than 386s.

Actually, with the 4M pages, it's not a question of luck any more - they just don't _have_ this bug, because on a machine with 4M pages the "cpu_has_pse" case handles this all and the buggy code is never actually entered.

Which explains why you'd only see this on a 386 (and I suspect your TLB size explanation is what saved some i486-class machines, although later i486 machines will have PSE as well).

The initialisation order is a dependency on actions, not on symbols. Code F cannot start until code E has initialised so execute E before F. This should have *NOTHING* to do with link order, but it is implemented as a side effect of link ordering which confuses people.

People need to realise that the problem is initialisation order, nothing more, nothing less. You have to determine and document the startup requirements for your code. Only you know what the startup pre-requisites for your code are, there is no way for another program to determine this from the source. Document your startup requirements, implement according to the documentation and your problems go away.

Initialisation order is not the problem, the implementation is the problem. The method currently used to control initialisation order sucks. It is better than the original method (lots of conditional calls in main.c) but it still sucks.

• Initialisation order is set by the order of structures in section .initcall.init.
• The order of the structures in .initcall.init is set by the order that objects are linked into vmlinux.
• The link order for vmlinux is derived from a combination of line order within a Makefile plus an overriding directory link order from the top level Makefile and parent Makefiles.
• Because order is a side effect of adding a line to a Makefile, the order requirements are rarely documented.

It is no wonder that people have problems getting the initialisation order correct.

I want to completely remove this multi layered method for setting initialisation order and go back to basics. I want the programmer to say "initialise E and F after G, H and I". The kernel build system works out the directed graph of initialisation order then controls the execution of startup code to satisfy this graph.

That still means controlling link order to achieve the required result. But with my approach the complexity would be handled by kbuild based on explicit rules which are documented in the local Makefile, instead of the complexity being handled by programmer via implicit rules scattered over several layers of Makefiles.

A typical graph would have scsi disk depends on scsi host adaptor group which depends on pci. Within the scsi host adaptor group you might need to initialise one driver before another, so just declare the few inter-driver dependencies. kbuild would automatically initialise pci then the scsi host adaptors (in the correct order) then scsi disk.

Most of the objects have fairly simple execution dependencies, e.g. all file systems depend on core fs code having already executed. There are no dependencies between most file systems so most file systems could initialise in any order (http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg10520.html) which means they could be linked in any order within the file system group.

I am ready and willing to code this method, it would make kbuild a lot easier to code, as well as making future maintainence a lot easier. Linus refuses to accept this approach. He insists that kernel coders explicitly specify the link order for everything, via Makefile order. As long as Linus insists on kernel coders explicitly controlling the entire link order, we are stuck with the current method. I have tried to change his mind without success.

The fact that it works on one board doesn't mean that it works on _every_ board.

This is, in fact, why I will _NOT_ accept anything but a simple auto-dma disable for this problem for early 2.4.x. I hope that people will continue to work on and debug this problem, but it's just been around for too long, and it's obvious enough that it doesn't happen with all hardware that I doubt there is any other reasonable solution that doesn't require some _very_ extensive testing to verify.

I'd love to see people who see these problems and are willing to test out patches to fix it. But in parallel with that, I definitely want the 2.2.x "disable auto-DMA" thing for the big public. We can enable it later if some patch does seem to fix it for good.

Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID.

Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does?

I've written a brief article on the topic of using test suites to test new linux kernels.

It is my hope that anyone who wants to play with the new kernels will try out some of these suites, not just people doing a formal QA process, so that more coverage of configurations can be achieved.

Using Test Suites to Validate the Linux Kernel http://linuxquality.sunsite.dk/articles/testsuites/

I cover the use of suites that test the correct functioning of applications (for example, language compliance tests for Python and Kaffe's Java implementation) as well as test suites aimed directly at testing Linux itself.

Links to five different packages with test suites are given. I'd appreciate hearing of any more that you know about.

I also appreciate your comments on how I can improve the article. This is a first draft.

I like them a lot too.

Without the changelogs Linus is just a "black box" which outputs random patches.

With a good changelog, we all have a much better idea what Linus wants and, consequently, what kind of patches we should give him (and which kind of patches we should wait with for a week or so).

Also, the changelog items are a good way to keep track of what's happening with the kernel, it makes it so much faster to track down exactly when a bug was fixed or introduced and what change had this effect.

Current half-assed changelog:

2.4.1-pre8:

• Don't drop a megabyte off the old-style memory size detection
• remember to UnlockPage() in ramfs_writepage()
• 3c59x driver update from Andrew Morton
• egcs-1.1.2 miscompiles depca: workaround by Andrew Morton
• dmfe.c module init fix: Andrew Morton
• dynamic XMM support. Andrea Arkangeli.
• ReiserFS merge
• USB hotplug updates/fixes
• boots on real i386 machines
• blk-14 from Jens Axboe
• fix DRM R128/AGP dependency
• fix n_tty "canon" mode SMP race
• ISDN fixes
• ppp UP deadlock attack fix
• FAT fat_cache SMP race fix
• VM balancing tuning
• Locked SHM segment deadlock fix
• fork() page table copy race fix

Reiserfs uses much more complex data structures then ext2 (trees..). I don't think that latency has ever been a design criteria and all of the benchmarks they use are pretty much pure throughput tests.

So it wouldn't be really surprising if reiserfs had very bad latency. You should apply the timepegs patch and profile your kernel latency to see where it's coming from.