Slashdot Mirror


Kernel 2.4.11 Released

stygian writes: "Linux 2.4.11...need I say more?" Of course you do. You need to point people to the mirrors and changelog, at a minimum.

14 of 386 comments (clear)

  1. Question for the Uber geeks. by A_Non_Moose · · Score: 2, Interesting

    Are there any issues known when upgrading older kernel versions?

    Got an old Redhat box with 2.2.16 (IIRC) and would like to bring it up to the latest stable release. Any chance of that being done easily?

    I've done incremental updates before but never major overhauls.

    Moose.

    "That is a valid question, now how about a valid answer." (I forget whom)

    --
    Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
  2. VM Changes by Goonie · · Score: 4, Interesting
    Back in 2.4.10, Linus made a fairly radical change in the virtual memory system - a rather unusual one for a stable kernel. While a lot of people are rather unhappy about it (notably Alan Cox, Rik Van Riel (the maintainer of the existing VM system), from all public accounts so far it seems that the new VM system works considerably better than the old one.

    So - - - Is that the case? Has there been any stability problems? Is the performance better (not that it really matters as a workstation user, but . .. )

    --

    Any sufficiently advanced technology is indistinguishable from a rigged demo
    --Andy Finkel (J. Klass?)
    1. Re:VM Changes by CraigParticle · · Score: 5, Interesting
      It shouldn't surprise anyone that 2.4.10 VM performs better than 2.4.9. Even in terms of the "traditional" 2.4 VM from Rik, the Linus and Alan trees deviated starting around kernel 2.4.7. There were numerous complaints about the Linus tree missing important patches, and having contradicting patches applied. It ended up quite a mess, and VM performance reflects this. Alan's tree was much more conservative in this regard.

      If you compare 2.4.11 to anything, please compare it to the latest -ac kernels from Alan, where the traditional 2.4 VM is actually working very well. There's NO sense in comparing 2.4.11 to 2.4.9; the VM in 2.4.9 and its kin -- it was just plain broken.

      Side note: In Rik's VM, please remember to not just look at swap used as a gauge of whether you're swapping or not. All anonymous pages are mapped to swap, so the space is simply allocated. You can create a huge image in GIMP and lots of swap will be allocated, but without a drop of disk I/O! Use vmstat and look at the 'si' and 'so' columns to see if you're actually writing pages to swap. Or look in /proc/meminfo and subtract "SwapCached" from the amount of swap you think you're using. That's the amount of *written* swap you're using (a better comparison to 2.4.10). This needs to be made sensible in 2.5, if this VM is to be resurrected.

      Andrea's work has cleaned up the handling of inactive pages (which could have been done under the old system), and the new "classzone" approach and VM balancing isn't documented anywhere outside the code itself. In addition, there are very normal loads where it performs badly compared to the -ac tree. Here is a test suite that tests different aspects of aging and swapping, and the results as provided to linux-kernel. 2.4.10 (patched with Andrea's VM tweaks) swapped more pages, took longer, and had to swap more pages back in when the tests completed (i.e. it could have chosen better pages to swap out). It also caused XMMS to skip mp3 playback throughout the tests, whereas -ac didn't.

      Nothing's perfect of course; a process that randomly walks through pages performs better in 2.4.10 since it's more streamlined and not trying to be as "intelligent" about page handling. Rik's code could no doubt be improved here.

      That's the great thing about open source: let the best idea win! No doubt in 2.5 we'll see these two VM schemes hash it out in much more complete form (i.e. lose the remaining kernel 2.2-isms, maybe add physical page mapping, almost certainly swapfs -- mostly for Rik's scheme; I'm not sure what the next steps for Andrea's VM should be).

  3. Re:Check out the Preemptible Kernel patches... by reaper20 · · Score: 3, Interesting

    These sound real good. Is there a reason that these patches are not the default behavior? Is there a downside to having a premptible kernel? Everyone that runs these patches says that they are awesome.

    I'm assuming that its not in 2.4 because it probably changes alot of things and needs to be done in 2.5.

  4. ext3 by hyperstation · · Score: 2, Interesting

    PLEASE for god's sake, merge ext3 into the kernel. it's nice and stable, and i'm sick of patching.

  5. Thoughts on the 2.4.10+ VM by Shane · · Score: 5, Interesting
    My personal feelings on the new VM is that it was the right decision. The VM problems have been going on for months. When people would report a problem, Rik would pretty much say: I don't have time to work on so and so.. feel free to pay me or convince my employeer to fund the work. Which is fine, that is his choice... But if I was Linus this would make me more open to looking at alternitive approches even if the short term risks were moderate.

    It is also interesting to note that Rik's vm core has had say 15 kernel releases (unstable + stable) to become stable and meet up to the expectations that Rik sold the kernel hackers on in the first place and judging from the reports on LK it is just now becoming stable enough for most work loads.

    The new 2.2.10+ VM had a couple minor to moderate problems for _SOME_ work loads but over all has received very good reports as far as I can tell for being so new. 2.4.11 is bound to be even better.

    Some people are complaining about the inclusion of major VM modifcations in the stable tree. I believe the truth is that most people that use Linux in production do not roll their own kernels. They use the vendor supplied kernels. Redhat for example will be releasing a 2.2.7-11-AC kernel which uses Rik's VM, it is what they have been testing for months and thus is what they will end up shipping. So the fact that Linus made this change in the "Stable" tree makes very little difference to me from a stability stand point, and I think it will prove to be a very good call in the short/medium/long run.

    Thats my 2 cents anyways.

    --
    -- You can be a geeklord too :)
    1. Re:Thoughts on the 2.4.10+ VM by Defiler · · Score: 2, Interesting

      VM in 2.4.10 is absolutely broken. The LKML is rife with reports of hangs, strange behavior, evil performance, etc, under heavy loads..

      Pretty much fixed in 2.4.10-ac10-eatcache. Almost as fixed in 2.4.11, but more work definitely needs to be done before a company like RedHat will be willing to ship one of these kernels with the new VM code.

    2. Re:Thoughts on the 2.4.10+ VM by Woko · · Score: 2, Interesting

      I believe the truth is that most people that use Linux in production do not roll their own kernels

      I don't think your right there at all. Companies are more likely to tweak the default installation, recompile the kernel for a known set of hardware, and then roll out a "company standard", using for instance RedHat's kickstart scripts.

      Using the stock kernel is made very difficult at least for RedHat users. RedHat's ongoing refusal to support reiserfs while installing, only recently while upgrading, and shipping (at least with 7.1 from memory) a reiserfs module that was significantly slower due to debugging being left on makes kernel recompilation necessary.

      I can understand their reservations, but faster fsck times isn't the only reason to move away from ext2

      --
      ---
      Silence is consent.
    3. Re:Thoughts on the 2.4.10+ VM by Shane · · Score: 2, Interesting

      Being someone who reads all the posts from the core kernel hackers (at least those that are public) I feel pretty confident in saying for the longest time Rik was to busy to fix bugs. Again he has this right.. Once other people started writting VM code (I think it started once pushonce was being tested by Daniel phillops) Rik has been churning out code at the rate he was in the pre 2.4 release days (back when he is bidding to get his code included). So I would not be suprised in the least that once pushonce was included that Rik patches have been ignored... the reason for which should be obvious Linus decided to take another direction with the VM and Rik's patches were incompatible with that direction.

      --
      -- You can be a geeklord too :)
    4. Re:Thoughts on the 2.4.10+ VM by Shane · · Score: 2, Interesting

      Linux has always been forked in certain areas. Just enver the VM before. Not to mention ALan has stated on LK that he is going to stick with Rik's VM until the other one proves out. He did NOT say that he will keep it until 2.5.

      --
      -- You can be a geeklord too :)
    5. Re:Thoughts on the 2.4.10+ VM by Isle · · Score: 2, Interesting

      But it interresting to see that Rik's VM did NOT start to perform well until Linux adopted Andreas VM. Rik started posted a bunch of fixes to Alan Cox just around 2.4.10pre7 or whenever the Linus made the change.

  6. Re:first winmodem driver in the kernel by AnimeFreak · · Score: 2, Interesting

    Isn't Connexant a subsiderary of Hewlett Packard? If so, then why wouldn't they release their source since HP is a big supporter of Unix?

  7. I won't run 2.4.11 by Stonehead · · Score: 4, Interesting

    Just like the majority of you readers, I am not a kernel developer. But I like to know what I'm running. My conclusion is that if you want a stable kernel, ignore Linus' tree and use the Alan Cox tree. To say it blunt, 2.4.10+ really is 2.5, and you should only run it if you are prepared for some weird behaviour.
    Now am I a troll? Hope not. I did get my info out of Kernel Traffic, which I've been reading for months. It is a very good, understandable and clear compression of all important things that happen on the linux kernel mailinglist. If you use Slashdot as your only information portal about the kernel, you are *braindead*.
    Ok, now my point - it is the VM subsystem. By now you should know that 2.4.x, until recently 2.4.10, used the VM code by Rik van Riel. That code has taken some time to develop, but you definitely can't blame Rik as the cause for all 2.4 stability problems, as well as the eternal delay of 2.5. But according to the l-k list, Linus himself made several errors in including Rik's patches, which indeed caused 2.4.7 and up to be unstable! Ok, now stop and think about this. Linus has an enormous responsibility. He didn't realize where the fault was, but he did perceive that the stable kernels were NOT stable. He knew that Andrea Arcangeli was still working on his own VM (that work improved Rik's VM too in 2.3. Not having a monopoly really does improve invention!) Then Linus made the big step: even in a *stable* series, he took over Andrea's VM and threw out Rik's one. This is really an important decision, and I applaud it!
    The only thing Linus should not have done, is labeling this thing 2.4.10. It really is 2.5. For the big public, that kernel was definitely everything but a stable kernel. Luckily a lot of problems have been solved since (2.4.11 is a hell of a lot better than 2.4.10), and I consider Andrea Arcangeli really a good coder, but actually I trust Alan Cox most. He commented that Linus' recent kernels trashed several boxes of his overnight. Alan really sees the -ac tree as the stable one currently. I run 2.4.9-ac18 too, with the kernel preemption patch as mentioned earlier, on a p2-233 with quite some load, and it doesn't show any strange behaviour. (The kernel preemption patch doesn't do really much here: I still get skips when I record an mp3 from my soundcard and switch desktops in the meantime. But I should not expect wonders :))
    One last thing: Rik van Riel's VM has improved *too*. Alan Cox catches up with his patches very speedily. No more big bugs; Rik even added some optimizations in 2.4.9-ac16. I can't see that of course, but overall the system is a lot more responsive than 2.4.3-pre6, my last kernel before this one.
    So my advice: use the ac-series of the kernel. Linus has made some wise decisions. I think he should start 2.5 and leave 2.4 to Alan, before people go sulking about 2.4.10 versus the always-stable reputation of the Linux kernel.

  8. Big Endian Reiser? by hey! · · Score: 3, Interesting

    Does anyone know the "Reiserfs cleanup" noted in the changelog include big-endian support?

    The base reiser code ONLY supports little endian architectures (shame!). I recently put one of my PPC based servers on the AC tree to get big-endian reiser support, but I've heard the AC tree patches have file fragmentation problems. I'm a little nervous about going live with this thing because of the reported VM problems and a potentially flaky reiserfs.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.