Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Software

New Kernel 2.4 Development Branch (-mjc) 197

Posted by michael from the wild-cherry-jello-seems-to-be-the-best dept.
Ivo writes: "kerneltrap is reporting: Michael Cohen announced to the lkml his intention to begin a new 2.4 development tree. The first release of his -mjc branch includes a number of performance enhancing patches, including Robert Love's preemptible kernel patch, Rick van Riel's reverse mapping patch and George Anzinger's real time scheduler patch. Michael says of this patch, "I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go. Feel free to test it""
This discussion has been archived. No new comments can be posted.

New Kernel 2.4 Development Branch (-mjc) More

New Kernel 2.4 Development Branch (-mjc)

Comments Filter:
  • but i'm afraid it will really confuse a lot of people out there . . . we have the 2.2 kernel tree, 2.4 kernel tree and 2.5 kernel tree already. now throwing in 2.4-mjc? yes extra performance enhancing stuff will be cool, but man are a lot of people going to be confused . . .

    • Re:this sounds really cool but (Score:4, Redundant)

      by Verteiron ( 224042 ) on Tuesday January 01, 2002 @12:10PM (#2770318) Homepage
      That's a question I had, as well... isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere? The appearance of one may prompt the appearance of others. It may not confuse us, but corporates looking at Linux may be stumped by the sudden availability of several different "versions" of the 2.4 kernel. And it's the exact sort of thing that Microsoft loves to make fun of Linux for (I recall a German magazine ad directed against Linux. It showed the same animal 4 times, but each time it had a different head. The gist of the ad was "Code forking is bad, Linux can be forked, so ignore the Win9x/WinNT thing and use Microsoft.").

      I think the terminology here should be used very carefully; these are patches to the official 2.4 kernel. Not kernel branches. Branches indicate disagreement between programmers (remember, corporate viewpoint here). Patches are just additions by independant groups, which is far more acceptable to the corporate mindset. I wouldn't make such a big deal of this, but this is a very delicate time for Linux. A lot of people are truly beginning to take it very seriously, and the one thing the Linux community needs to do is present a united front to the people inspecting it. Any indication, real or perceived, of internal turmoil will drive businesses (and individual users) away.
      • That's a question I had, as well... isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere?

        When most people think Linux, they think of the operating system as a whole, and on that level we already have many multiple branches and forks. Debian, Redhat, Mandrake, etc...

        If I was to pick a big selling point for Linux, it would be based on price and customisability - this branch targets Linux on the workstation whilst the official branch is more aimed at servers, or at least that's how I understand it.

        I agree with you to a certain extent that terminology is important. Perhaps it should be given a catchy unofficial slogan, like "Desktop optimised", or "Linux for Workstations", or some such thing.
        • If I was to pick a big selling point for Linux, it would be based on price and customisability - this branch targets Linux on the workstation whilst the official branch is more aimed at servers, or at least that's how I understand it.
          Not exactly, but thats probally how it works out in practice. Production servers tend to require 5 9's of reliability. If the latest kernel patch that provides better page swapping or whatever isn't as throughly tested as the 2.2 or 2.4 kernel, its not going to be incorporated into your production servers. However, for your workstations, having to restart X to get rid of memory leaks once a month or so isn't that big a deal. For workstations people are mnore likely to use 2.4 kernels with patches.
          • For workstations people are mnore likely to use 2.4 kernels with patches.

            Yes, people (read as: geeks) like us /.'ers will. Sure. I'm LITTERALY recompiling my kernel as I type this with the above mentioned patches. But that's not the issue. This is about the (L)users. People who don't or can't know this stuff. To say "people" (read as: general public) I think requires a bit of a disclaimer at the end (so to speak, I don't mean it litteraly). The public doesn't know or care about this stuff, they just want to have the stupid thing work when they press the power button. That's all they know or care to know about "computers".

      • isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere? The appearance of one may prompt the appearance of others.

        There are others. Lots of others. Always have been. Those branches are essential to the development of Linux, as Linus explains [theaimsgroup.com]. It is important to note that all those branches are compatible: their implementation is different, but they all look the same from userland.

        I think the terminology here should be used very carefully; these are patches to the official 2.4 kernel. Not kernel branches.

        The terminology is used very carefully. Patches and branches are two quite different things.


      • isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere?

        No. None of the major distributions ship with a plain Linus or -ac kernel. They all apply different patches in order to pass their own test suites. And from the point of view of the vast majority of users the kernel doesn't matter anyway - it is the distribution as a whole that they see, and there are literally hundreds of different distributions. As far as corporations are concerned it's a good thing. It lets them choose the distribution and kernel patches that they feel is the best.
        • Slackware has always used an unpatched kernel and managed to keep its high stability level intact... (the Reiser patch in Slack8 being the only exception I can remember, and it was unnecessary unless you were using a Reiser FS)

          Of course you may not think Slack's a major distro, but there are those who would beg to differ ;)

      • This is an excellent move to make. I'd prefer that it be accomplished with compile-time directives[*] rather than another series of kernels but it's still a great move.

        This is -exactly- what MS does with their kernels. It's really a great move. Think Win2k pro, server, advanced server, and datacenter server versions. They have different kernels. Different schedules, different priorities. It's great. It scares some people but the thing to remember is that there are NO API CHANGES going on here. It doesen't matter if you're running the -ac tree, the Linus tree or this new one. The application doesn't even need to be recompiled to move kernels.

        *Doing something like that would be a coding nightmare and things would be -really- ugly looking. The pre-empt patch touches alot of places in the kernel and I'd hate to see code with a bunch of #ifdef's splattered about. When I say it'd be nice I mean nice from a user point of view, not as a coder or somebody who cares about things working right.
        • This is -exactly- what MS does with their kernels. It's really a great move. Think Win2k pro, server, advanced server, and datacenter server versions. They have different kernels.

          Is that so? (If so, good move.) NT4 didn't. NT Workstation and NT Server shared the same kernel - or kernels, actually, a UP kernel and an SMP kernel.

          Considering the quite different instruction scheduling properties of the Pentium/Pentium-MMX from CPUs that came before and after it, the fact that MS doesn't ship kernels compiled to optimise for a given CPU must have hurt. I don't know if they have any other measures to compensate.

          ("Must have hurt", past tense, because they almost certainly no longer optimise for a Pentium, if they ever did. And subsequent Intel CPUs are much more "compatible" in the optimisation sense.)

      • That's a question I had, as well... isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere?



        Good question, and good points. For me, though, one of the big selling points of Linux is that there can be branches and forks. The "right to fork," to me, is what makes free software free and what makes free software better. (That's why I've decided the GNU/Linux vs. Linux debate is all wrong; just call Linux a fork of GNU.)



        The thing is, we just have to learn to fork in a civilized manner and not give bad impressions to the outside world. It looks like this is an excellent example of a civilized fork (but I don't read lkml, so there may be same flaming over it; who knows). Along with you, I hope it doesn't give the wrong impression to the outside world.

      • I think the terminology here should be used very carefully; these are patches to the official 2.4 kernel. Not kernel branches. Branches indicate disagreement between programmers (remember, corporate viewpoint here).

        Spin. They are branches. Ask AC or Linus, they'll call 'em branches, and AC will tell you chapter and verse where he thinks Linus is a complete bonehead for doing or not doing x, y, or z and why it isn't that way in -ac. They're all binary compatible with each other, they're configuration differences, not architecture differences. What they're not are forks. LinuxPPC and ucLinux, to name a couple, are forks.
    • I don't think there will be a problem, after all the AC branch has been around for a long time. I got from the report is this new branch will replace the AC branch now that Alan Cox has moved onto 2.5 development. Besides I see no reason to srop development on the 2.4 branch just because Linus opened 2.5, people are going to be using the 2.4 kernel for along time to come. So I say Why Not ?
      • Maybee I'm a bit of a n00b, but I thought the point of a 2.5 was for new development and experimental code. Bug fixes, stability, and tuning sound great in the 2.4.x series - I _USE_ that kernel series (usually a couple revs behind) for real development work, not just for play on a scratch box that can be fdisk'ed on a whim.

        When the 2.5 stuff gets up to snuff, I'm sure we will see a 2.6 released (rebranded, perhaps). By moving stuff into dev that needs to be in dev, we might not have the LONG wait we like the 2.4 series did before it hit prime time.
        • You are correct, the 2.5 kernel is the development kernel. The difference is the 2.5 kernel is targeted to eventually become 2.6 or possibly 3.0. This new branch -mjc is specificly for developing and testing new features/bug fixes for the 2.4.x kernel.
    • I don't think an extra kernel source tree will really add much confusion. We'll always have the stable base 2.4 and the seat of your pants 2.5. MJC and AC will be something in between.

      And MJC will live and die by how well it's mantained.
    • Well, I agree with you possibly. They need more time to become household names as well as good branding. After all, are you that confused that there's an OpenBSD, FreeBSD, NetBSD, and BSD/OS? It confused me at first, but it took 10 minutes of research to figure it all out. Not to mention one is at 3.0, another is at 4.4 (or is that 4.5) etc etc..

      If there are different goals, not a bad choice for fragmenting.
    • but i'm afraid it will really confuse a lot of people out there

      Yes but confuse which people? If you aren't willing to keep up with the issues of 2.0.x vs 2.2.x vs 2.2.x-ac vs 2.4.x vs 2.4.x-ac vs 2.4.x-mjc vs 2.5.x vs 2.5.x-dj, you will probably do just fine running your vendor-installed kernel, which is yet another branch, generally.

      Now I don't get confused about those eight major branches - but hey, what a coincidence, I'm the target audience for some of those branches.

      Does anyone in the real world care about the two branches of HP-UX 11.00? That is, the standard release and the ccr builds? What, you say? You've never heard of 11.00-ccr? My point exactly. Most people don't need to know or care.

  • 2.4? 2.5? (Score:3, Insightful)

    by Bert64 ( 520050 ) <bert AT slashdot DOT firenzee DOT com> on Tuesday January 01, 2002 @12:08PM (#2770313) Homepage
    Isn`t 2.5 where the "fast paced" development is supposed to take place? anyway, i`m all for performance enhancing patches.. i run some fairly old hardware here for money saving purposes. The kpreempt patch seems to work well on x86, but it would be nice to see it ported to the alpha.. Is -mjc going to keep up with the performance related patches added to 2.5, and backport them?
    • Re-read, wrong bit is fast :-)

      2.5 is for bleeding edge development, pushing linux into the future. 2.4-mjc is a funny 2.4 which is focussing on improving system performance.

      Not sure whether this is a good idea (heck, doesn't affect me much, using Win2K here...) but that's what's going on here :-)

    • Re:2.4? 2.5? (Score:5, Interesting)

      by Zog ( 12506 ) <israelshirk@g[ ]l.com ['mai' in gap]> on Tuesday January 01, 2002 @12:29PM (#2770359) Homepage
      Is -mjc going to keep up with the performance related patches added to 2.5, and backport them?


      Most of the performace patches (pre-emptible, etc) are just patches to the current kernels that the stable kernel's maintainer hasn't accepted, for one reason or another. Chances are, they will go straight into 2.5 so that they can be tested and improved upon.

      The reason for -mjc is to allow people to use the performance patches without having to worry about conflicts between the patches, applying them, etc - it looks just like a normal kernel package, except with -mjc at the end.

      The -ac series follows the same guidelines - it tends to have slightly fancier features, newer drivers, etc. Every once in a while, when the stable kernel's maintainer decides that the -ac series is stable enough, a lot of the patches that went into -ac are put into the stable series, to get all the new drivers in there.

      I doubt that will happen the same way for -mjc, since the patches are more along the lines of getting every little bit of performance possible, instead of having a wide testing ground for new drivers, vm's, etc.
  • So how much gain in performance (or apparent performance) should one expect after applying this combined patch? Are the performance gains only applicable under special circumstances? Are they focused more on desktop apps than server?

    • Now this is the question of the day. I never used the AC kernel because I prefered to stick closer to stable tree, but I did add patches as I needed them. The VM stuff did wonders for me, but the PreEmpt patch made no noticable difference, probably because I use a dual processor system.

      Of the included patches; Reverse Mapping patch #9, Preemptible Kernel Patch, Lock-Break Patch, CPU affinity /proc entry, Netdev-random, Software Suspend, Real Time Scheduler for Linux, IDE updates. Which ones can we expect to have an impact on preformance ? and which ones simply fix a long standing problem ?

      • but the PreEmpt patch made no noticable difference, probably because I use a dual processor system.

        Agreed, SMP makes preempt a lot less necessary.

        Of the included patches; Reverse Mapping patch #9, Preemptible Kernel Patch, Lock-Break Patch, CPU affinity /proc entry, Netdev-random, Software Suspend, Real Time Scheduler for Linux, IDE updates. Which ones can we expect to have an impact on preformance ? and which ones simply fix a long standing problem?

        I'm not sure about all of them, but:

        • Reverse Mapping: not sure if it helps VM performance by itself but it was designed to make it easier to perform certain VM-related optimisations.
        • Preemptible: you know what this one does - for UP systems in particular, should give lower latency. Good especially for smoother interactive feel (eg. mouse movements) and multimedia (eg. no-skip sound playback). Small performance hit.
        • Lock-Break: not sure what this is. I think it's about bug reporting - shouldn't be noticed in real life.
        • CPU affinity /proc entry: lets you associate a specific job with a specific CPU. "If you don't know whether you need it or not, you don't." Used to override the scheduler when you think you're smarter than it.
        • Netdev-random: collect entropy out of incoming network packet timings. Good especially for a headless, diskless server (like a floppy-based router) because most of the usual sources of entropy aren't present. Bad in that an external source can control your entropy input - considered a security risk by purists. Linus rejected this one because of objections on L-K by Ted Ts'o and others. You shouldn't need this on the desktop. Probably minimal performance impact.
        • Software suspend: save memory and device state to disk before letting a laptop (or a desktop I suppose) go to sleep or shut down - then restore on wakeup / bootup. Probably no performance impact, just a new feature. As you'll know if you use this on Windows 98 or Win2k, reliability is a big problem with this sort of thing thanks to its extreme dependence on hardware behaving to spec on power management issues.
        • Realtime Scheduler: allow a process to hog the CPU and have it basically any time it wants. Again, probably for multimedia purposes, or data collection, or other real-time tasks. I don't know the implementation details, or how hard the guarantees are.
        • IDE updates: Andre Hedrick and Linus Torvalds, um, do not get along very well. It's not personal (or not only that), Linus doesn't like Andre's philosophy of development - Andre sits on the IDE standards board, and in Linus's opinion trusts the standards too blindly - whereas Linus comes from a background of assuming that hardware won't follow its specs so you have to dig in and figure out what it does not just what it says it does.
          This adds up to the sad fact that official 2.2 and 2.4 kernels are never even close to up-to-date w/r/t Hedrick's IDE work. New IDE drivers, random bug fixes, etc.

        HTH.

    • Re:Real world impact? (Score:5, Informative)

      by blakestah ( 91866 ) <blakestah@gmail.com> on Tuesday January 01, 2002 @12:48PM (#2770397) Homepage
      So how much gain in performance (or apparent performance) should one expect after applying this combined patch? Are the performance gains only applicable under special circumstances? Are they focused more on desktop apps than server?

      I doubt you will see ANY performance enhancements with this patch - in fact, under most circumstances, performance will be worse.

      The patch MOSTLY addresses a need to have shorter latency responses under linux. So the real benefit will be seen if you, say, run xmms, browse the web on a java intensive site, and do a make -j10 bzImage at the same time. On most machines this will cause xmms to stutter a little - either an audio skip or the text in the scrolling windows will stop and start. With the patch you can expect perfect xmms performance under broader circumstances.

      This has the most significant implications for audio and video under linux - things that require short latencies to perform properly. This is questionably the most needed area of improvement for the linux kernel for desktop use.

      However, if you time kernel compiles or run lmbench, you'll probably see slightly (but not hugely) worse results. You can expect that changes to address these issues will be incorporated in mainline kernels eventually, although not necessarily in the form that these patches take. Maybe - it will be interesting to see it sort out.
      • Most ./ readers seem to think that it is all about Servers vs. The Desktop.

        I can safely say: IT IS NOT!!!

        For a great deal of embedded applications it is a necessity to have lower and deterministic latency. Therefore these patches will raise the acceptance of Linux as an alternative embedded OS.

        I guess it will be a long time though before Linux itself will have REALLY low (microseconds) latencies and hard real time behaviour. Right now this can only be achieved with addons like RTAI or RTLinux.

        The RTAI and RTLinux addons are really real time schedulers that run the Linux kernel as lowest priority thread. This gives an added complexity for the real time programmer. But maybe this "sandbox" approach is really a good thing and the way to go for hard real time, as it will be almost impossible to guarantee hard real time with a complex beast like the Linux kernel.

        But for many applications the latency and quality of service you can get with the patched kernel will probably be enough - so keep up the good work!!! :-)
  • Nothing is wrong with fragmentation. It might be amusing and good to see 3 Linux's on the scene. Hope the reasons for splitting would be more.. friendly than not. After all, has anyone really criticized the existance of 5 BSDs? Net,Open,Free,BSD/OS and Darwin. At least binary compatability would remain, no?

    Ok, so maybe I'm just being devil's advocate. :)

    • Re:FreeLinux, OpenLinux, NetLinux? (Score:4, Insightful)

      by rtaylor ( 70602 ) on Tuesday January 01, 2002 @02:29PM (#2770654) Homepage
      If you really wanted to get technical FreeBSD is heavily fragmented within for the purpose of code creation without toe stepping.

      TrustedBSD, SMPng, and KSE stuff were all seperate BSDs (temporarily anyway).

      Branching source for the purpose of better co-ordinating development without forcing others to wade through your broken source or wait on you is a good thing.

      However, I'm not overly fond of Linux branching for development by indivials rather than for a specific project -- but thats just a labelling issue :)
      • You are absolutely right.

        I guess what it really comes down to is when the best of the best of all the branching is found, is it possible to remerge and is it in thebest interest to.

        Hey, maybe the individuals may "lead the way" for certain projects in the end.
    • The Devil understands the situation better than you do, and since you mentioned Darwin, read up on Linus' thoughts on how the Linux kernel evolves, it might help.

      See, the -ac series was a testbed series of kernels, often used in practice, as patches to the mainline kernel. It was not a fork, and neither is this.

      2.4.5-ac3, for example, would be Alan Cox's third patch release to Linus' 2.4.5. Now, Michael will be doing the same thing with Marcelo's kernels.
      • Oh, I understand the role that -ac holds, but if anything, FreeBSD and -ac have similarities in that they are used more than OBsd and NetBSD for adding new features. I'd suspect that the non-branch more akin to NetBSD. Only difference between BSD's and Linux is that the -ac stuff gets put back into the "main branch".

        It wouldn't be bad in the end if Linux did fork though.
  • Wouldn't this be percieved as the "fragmenting" of Linux? I thought the newest stuff was to be included in the 2.5.x series ?

    • Re:Linux Fragmentation (Score:3, Insightful)

      by erat ( 2665 )
      The whole idea of keeping things like the Linux kernel open is to allow things like fragmentation to happen. If you don't want to use the "-abc" kernels, they're easy to identify, so you shouldn't have any problem avoiding them.

      Now, if someone made their own fork and named the files exactly the same as the "real" Linux kernel (i.e. not Alan Cox's, or any other non-Linus blessed kernel), then there would be problems. I'm not worried about this at all. In fact, I'm glad to see others who are either impatient with the slowness of Linus' team or are fed up with the petty bickering over crap like VMs pick up the ball and do things their way. And as always, if these one-off kernels have cool stuff, Linus and his merry men are free to harvest what they like and incorporate the stuff into their source tree.

      One person's fragmentation is another person's diversification. This kind of fragmentation gave us multiple Linux distributions, embedded Linux innovations, and a host of other things that lots of folks are thankful to have.

  • news? (Score:1)

    by orz ( 88387 )
    Okay, someone applied some patches to 2.4 and named the result after himself. This is front pages slashdot news, why?

  • New kernel tree akin to ac tree. (Score:4, Insightful)

    by Zapman ( 2662 ) on Tuesday January 01, 2002 @12:22PM (#2770345)
    Read what the maintainer says on the slashdot article:

    "I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go." --Michael

    The -ac tree has moved on to the 2.5 world. He feels the need that -ac filled in the 2.4 world is still there, so he's doing something about it. This really isn't any more fragmentation than there was beforehand.

    The -ac tree existed as a 2.4 (and 2.2 before it, and 2.0 before that) testbed (sort of a development kernel in the stable kernel code) that saw a decent bit of testing from developers. People could submit patches to Alan, and they had a much better chance of getting included. After they'd been tested for a few versions, and cleaned up some, and whatnot, the patch would go to Linus for inclusion in 2.4. Michael is offering his services to do the same job now that -ac has moved on to 2.5.

  • ... Rick van Riel's reverse mapping patch ...

    I just thought I should mention that it should be Rik van Riel, not Rick.

  • PalmOS -mj branch (Score:1, Funny)

    by Anonymous Coward
    I knew it had to happen one day! First the PalmOS has the -mj branch [jordanedition.com], and now linux does, too. True, we have the -ac branch and palm doesn't, but I'm still waiting for the Palm -cs branch [claudiaschiffer.com] to be ported over to linux.

  • It's funny. With all these naysayers who say they only want ONE branch, you have to begin to wonder what the benefits of open source are really supposed to be to them. The ability to grab source and create an improvement is the heart and soul of open source. If you don't like that, do yourself a favor and run windows. Or something.

    C//
  • Will this new dev patch increase performance when playing Linux Quake on my 486DX/2??
    • I personally like doom1 better then quake1 and I find the graphics better. Doom1 and Doom2 run fluidly on 486 systems with decent video cards. You would need the windows program Kali to play an internet game. I don't think there is a linux equilivant. Doom1 and Doom2 are freely available now and there is an active linuxdoom port believe it or not. Just don't download the really old one from idsoftware. ITs not compatible with any linux version above 1.1x. Try Tkdoom which is currently under active development and should run on modern linux kernels. It may eat up memory on your 486 though.
  • a stable Kernel is because the're not stable or they're not a performace enhancement. Robert Love's "preemptable kernel patch" will crash an SMP system with certain drivers. If you have a UP system or you know your hardware is kosher then you'll be OK. I don't think it's for production systems. It's more of a desktop performace enhancement. As for Rik's reverse mapping VM code, the last graphs from Safemode (it's a person), showed Andrea's VM still performed better. In fact, Rik's code still has problems on low memory systems (caused a lockup in one of Safemode's tests). But of course it's good to see these patches getting some visability. They might prove to be useful after some time.

Slashdot Top Deals

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Close