Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 2.6.38 Released

Posted by timothy on from the this-is-your-kernel-on-speed dept.

darthcamaro writes "The new Linux 2.6.38 kernel is now out, and it's got a long list of performance improvements that should make Linux a whole lot faster. The kernel includes support for Transparent Huge Pages, Transmit Packet Steering (XPS), automatic process grouping, and a new RCU (Read/Copy/Update)-based path name lookup. '"This patch series was both controversial and experimental when it went in, but we're very hopeful of seeing speedups," James Bottomley, distinguished engineer at Novell said. "Just to set expectations correctly, the dcache/path lookup improvements really only impact workloads with large metadata modifications, so the big iron workloads (like databases) will likely see no change. However, stuff that critically involves metadata, like running a mail server (the postmark benchmark) should improve quite a bit."'"

101 of 159 comments (clear)

  1. Kernel Newbies link by Anonymous Coward · · Score: 5, Informative

    Informative as usual: http://kernelnewbies.org/Linux_2_6_38

    1. Re:Kernel Newbies link by Anonymous Coward · · Score: 1

      "B.A.T.M.A.N. Mesh protocol"
      Now things are getting good.

    2. Re:Kernel Newbies link by davester666 · · Score: 1

      Really?
      "we're very hopeful of seeing speedups"
      This sounds so reassuring to somebody with a rack full of linux machines.

      --
      Sleep your way to a whiter smile...date a dentist!
    3. Re:Kernel Newbies link by kokoko1 · · Score: 2

      Better Approach To Mobile Adhoc Networking

      --
      http://askaralikhan.blogspot.com/
  2. Re:A now untrusted source of information by troon · · Score: 2

    It isn't sloppy. The kernel is the heart of the operating system, and the quote you extracted is precisely correct.

    --
    Ydco co ,df C erb-y go. a Ekrpat t.fxrapev
  3. 200-line patch by Tubal-Cain · · Score: 1

    Isn't this the version that 200-line patch was slated for?

    1. Re:200-line patch by WrongSizeGlass · · Score: 2

      Isn't this the version that 200-line patch was slated for?

      I'm pretty sure that's what "automatic process grouping" is.

    2. Re:200-line patch by neokushan · · Score: 1

      aka "the wonder patch".

      As someone who knows bugger all about Linux, can anyone confirm if that patch will have any kind of impact on Android Devices or is it the kind of thing only a desktop user will see a difference with?

      --
      +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    3. Re:200-line patch by blair1q · · Score: 2

      i think that's the wonder of it

      because i wonder what it will do, too

      albeit, i haven't followed kernel fixes for years

      i imagine someone's found a way to fake priority by treating a group of processes as one process when allocating cpu, because it solves one problem someone was having while causing someone else a problem

      the example was forking 20 compile processes. normally that's a big speedup because when one has to pend on some i/o, another can pick up and do some work on your overall compile. with this new scheduling instead of 20 new processes crowding the few existing processes into much less cpu, now the 20 processes only act like one new process

      which makes me wonder why you'd fork 20 processes any more, since they'll have only one process' share of the resource. might as well run them sequentially; it'll take almost exactly as long

      unless that example wasn't the benchmark we're looking for...

    4. Re:200-line patch by Junta · · Score: 1

      I would say most dektop users won't even notice this. It may prevent fork-heavy things like Chrome from starving other things, but the best cases to demonstrate was 'make -j ', in a terminal, which isn't particularly indicative of most user load.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    5. Re:200-line patch by crazycheetah · · Score: 1

      If Google decides to include this patch with their fork of the kernel, then yes. But the two kernels, while essentially the same, are two different branches of the same tree now, really*. Google may go ahead and put a lot of this into their kernel, but they might not. I wouldn't ever *expect* it to go into Android, personally, but I may just be quite happy if it does.

      * I may be off about this, as I haven't kept up too well on the details, but last I ever heard, the Linux kernel as used by the desktop distributions and Android's Linux kernel are moving roughly in their own directions. Perhaps someone else could shed better light on that.

    6. Re:200-line patch by Wrath0fb0b · · Score: 4, Informative

      As someone who knows bugger all about Linux, can anyone confirm if that patch will have any kind of impact on Android Devices or is it the kind of thing only a desktop user will see a difference with?

      The Android kernel and the Linux kernel are pretty much irreparably forked, after the Linux people (perhaps rightly, I don't know) refused to accept the Android patches back into the trunk over the wakelock controversy. Unfortunately, the rift there never healed and there was never any real resolution.

      In order for this to apply to Android, Google would have to port the changes over.

    7. Re:200-line patch by butalearner · · Score: 4, Informative

      Isn't this the version that 200-line patch was slated for?

      I'm pretty sure that's what "automatic process grouping" is.

      Yup. Some links:

      • This LWN talks about the switch from TTY-based grouping to session ID-based grouping.
      • Lennart Poettering's alternative solution using cgroups, which works perfectly fine as long as you don't care the changes are in user space (i.e. you have to manually set this up on each computer).
      • Another alternative is using Con Kolivas' BFS, which reportedly shows similar improvements, not to mention actually pays attention to nice levels. Of course you actually have to build your own kernel, or get it from someone else, or use a distro that uses it by default like PCLinuxOS or Zenwalk.
    8. Re:200-line patch by Timothy+Brownawell · · Score: 5, Informative

      the example was forking 20 compile processes. normally that's a big speedup because when one has to pend on some i/o, another can pick up and do some work on your overall compile. with this new scheduling instead of 20 new processes crowding the few existing processes into much less cpu, now the 20 processes only act like one new process which makes me wonder why you'd fork 20 processes any more, since they'll have only one process' share of the resource. might as well run them sequentially; it'll take almost exactly as long

      Say you have regular desktop programs that take some small amount of CPU, and you want to be able to compile things a quickly as possible without making your music skip or your window manager get laggy. Before this you would have to guess at the right number of compile processes to run; too few and it takes longer and doesn't use all your CPU, too many and your desktop gets laggy. Now, the scheduler treats all of the compiler processes as a group, and lets your music player and window manager steal CPU cycles from them more easily -- so you can run more processes and keep the CPU busy, without worrying about your music skipping.

    9. Re:200-line patch by blair1q · · Score: 1

      Figured it might be like that.
      Personally I look for ways to peg the CPU. 8 cores at 2.8 GHz running web browsers ain't doing it most days.
      I wonder if there's a patch for that.

    10. Re:200-line patch by Tetsujin · · Score: 5, Informative

      i think that's the wonder of it

      because i wonder what it will do, too

      albeit, i haven't followed kernel fixes for years

      i imagine someone's found a way to fake priority by treating a group of processes as one process when allocating cpu, because it solves one problem someone was having while causing someone else a problem

      the example was forking 20 compile processes. normally that's a big speedup because when one has to pend on some i/o, another can pick up and do some work on your overall compile. with this new scheduling instead of 20 new processes crowding the few existing processes into much less cpu, now the 20 processes only act like one new process

      which makes me wonder why you'd fork 20 processes any more, since they'll have only one process' share of the resource

      That's not quite right.

      Basically, there are lots of conditions that could cause any process to give up its time slice. Your network application may be waiting for packets to process. Your video player may have decoded all the compressed video it needs for the moment, etc. The idea here is that certain programs, even if they're not doing a whole lot of work at any given time, still need frequent service so they can keep doing what they need to do.

      If your machine were running 3 processes (in separate groups) and you ran another 20 in a single group, those 20 processes wouldn't wind up limited to 25% of the CPU time. In all likelihood, they'd continue using the lion's share of the machine's resources until the job is done.

      What this scheme does do is help out those other three processes: instead of getting 1 time slice each out of every 23 to see if they have work to do, they'll get one out of every four (via group scheduling). If they have a bunch of work to do, this means they'll effectively have higher priority than the individual processes in that big job. But if they're largely idle, the big job will be able to consume the left-over CPU time.

      So it's not a perfect system, and it's not any kind of CPU quota system or QoS system, it doesn't really restrict what processes on the system can do. It's a hint for the scheduler, to try and give priority to processes that need it.

      --
      Bow-ties are cool.
    11. Re:200-line patch by neokushan · · Score: 1

      I didn't know about this, that was quite a fascinating read. However, I did find the last line of the first article particularly amusing - "As for me, I think I'll look into getting a Nokia N900. It looks much more open, with the code mostly all upstream, and a much more active developer community.".
      Hindsight is a wonderful thing.

      --
      +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    12. Re:200-line patch by Timothy+Brownawell · · Score: 3, Informative

      (And if it's completely IO bound, there's never been any reason to fork it 20 ways.)

      That depends on why it's IO bound. If you're saturating available bandwidth then yes, but for example if you're trying to crawl a bunch of really slow webservers on the far side of the internet (high round-trip time) then you'd really want to have several outstanding requests at any given time. Even if you're IO bound against local disk parallelism can sometimes help a little, since it gives the IO scheduler more to work with.

    13. Re:200-line patch by PhrstBrn · · Score: 2

      Say you have a machine with 16 cores total. Person A runs a compile that runs on 16 processes. Person B runs a program that runs on 1 processor.

      The old model says that Person A gets 16 shares, and Person B gets 1 share of CPU time. The new model says person A and B both get 50% share of the CPU time.

      In the old model, Person A will hog all of 15 cores, and end up using about half of the 16th core. Person B will only be able to use 50% of one core. In the new model, Person A will be able to use all of 15 cores, and Person B will end up being able to use all of the 16th core.

      You can see in the old model, Person B is penalized for only running one process, and Person A is monopolizing the CPU. In the new model, Person B is able to use all of 1 CPU, while Person A is able to use the reset of the cores without interfering with Person B.

      Your compiles may run slower, but it won't interfere with everything else on the system because you wanted to hog all the resources. Each processor group has equal shares to processor time, not each process.

    14. Re:200-line patch by mr_lizard13 · · Score: 1

      the example was forking 20 compile processes. normally that's a big speedup

      It's a forking hell.

      --
      "We live in a global world" - Harvey Pitt, former Securities and Exchange Commission Chairman
    15. Re:200-line patch by Anonymous Coward · · Score: 2, Funny

      Figured it might be like that.
      Personally I look for ways to peg the CPU. 8 cores at 2.8 GHz running web browsers ain't doing it most days.
      I wonder if there's a patch for that.

      That's what the System Idle process is for. So it looks like you'll have to move to Windows if you want to utiize your system to the maximum.

    16. Re:200-line patch by pantherace · · Score: 1

      Blender, yafaray, and some others, especially look at the fluid simulation (and turn up the resolution!)

      There: all the 2.8GHz CPU pegging you want.

    17. Re:200-line patch by lee1 · · Score: 2

      Does this mean that it's as fast as BeOS now?

    18. Re:200-line patch by vga_init · · Score: 4, Insightful

      In my opinion, Android isn't the first Linux-based project to rely on a custom kernel. I've seen many such systems pop up in the industry, most of them dead and gone now. The reason is that once the fork has been created, it falls out of development and becomes obsolete after a time. The Linux kernel has been customized and forked by projects countless times. What's going to happen is that the fork is simply going to become outdated and once it's obsolete, the current Linux kernel will have to be forked yet again. Re-forking becomes inevitable part of the project's continued development.

    19. Re:200-line patch by Runaway1956 · · Score: 1

      I don't see it having much if any impact on an Android device. In fact, relatively few desktop users will actually see any improvement. I'm not smart enough to get technical - but everything I've read seems to say that unless you are a multitasker who works his desktop pretty hard, the improvements will mean little to you.

      One of the little tests that was offered to prove the usefulness of the wonder patch, was to do some routine things on your desktop, loading the CPU up near capacity. Once all your stuff was running, then start compiling something. The responsiveness of your desktop apps was not impacted by the background work, even though your CPU(s) was working hard.

      So, unless you use your Android for some pretty intensive multi-tasking, no, you won't see any real difference in real use.

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
    20. Re:200-line patch by gmhowell · · Score: 2

      Figured it might be like that.
      Personally I look for ways to peg the CPU. 8 cores at 2.8 GHz running web browsers ain't doing it most days.
      I wonder if there's a patch for that.

      Yeah, it's called FlashPlayer.exe

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    21. Re:200-line patch by RobbieThe1st · · Score: 1

      Possibly your Android's not as useful as my N900, but I routinely -do- load it up with a half-dozen programs and another half-dozen web windows. It works fine, but if you try to do any task that does compression/decompression... it lags things down. So, no background apt updates if you want to work.
      I'd certainly make use of some of this... but I probably won't be able to unless someone backports it to 2.6.28 due to the damn proprietary graphics drivers.

    22. Re:200-line patch by smellotron · · Score: 2

      (And if it's completely IO bound, there's never been any reason to fork it 20 ways.)

      I can think of a few reasons:

      1. Code with blocking I/O is easier to write than asynchronous I/O. The system calls are easier. The inter-task scheduling is managed People Who Get Paid To Do That instead of the local application developer, which means it's less prone to weird corner cases like starvation or lost signals.
      2. Some per-process limitation crops up, such as a 32-bit memory space ceiling or a ulimit. Splitting tasks into multiple processes allows the kernel to manage a larger amount of resources (virtual memory, open file descriptors, what-have-you) than can any single process.
      3. Some inherent unreliability exists in the system, such as dynamic linkage to plugins like FlashPlayer.exe or mod_php.so. Splitting tasks into multiple processes allows one of them to die in a fire after shitting all over its own stack.
    23. Re:200-line patch by kvvbassboy · · Score: 1

      I would say most dektop users won't even notice this. It may prevent fork-heavy things like Chrome from starving other things, but the best cases to demonstrate was 'make -j ', in a terminal, which isn't particularly indicative of most user load.

      Umm.. a poster above spoke about this patch in terms of Person A and Person B, so I am assuming it's a patch which distributes computing resources in a more fair manner among users accessing the system simultaneously. So, no desktop user will ever notice this as only one user accesses the machine ever. If this is what it is, it is extremely similar to a project I did two semesters back. xD

    24. Re:200-line patch by bedouin · · Score: 1

      Linux will never achieve that feat.

    25. Re:200-line patch by kobaz · · Score: 1

      Another alternative is using Con Kolivas' BFS, which reportedly shows similar improvements, not to mention actually pays attention to nice levels.

      How do the current built in schedulers handle nice levels?

      --

      The goal of computer science is to build something that will last at least until we've finished building it.
    26. Re:200-line patch by Carewolf · · Score: 1

      If you know bugger all about Linux, you probably wouldn't even see any difference on a desktop. This patch mainly do wonders for developers doing big parallel builds, and some automatic improvements if you have a classic multi-user server, but all the same improvements were available before this patch too, they just weren't automatic.

    27. Re:200-line patch by Carewolf · · Score: 1

      That said. I find it cute that people wants to improve the user-experience when compiling big jobs on their android phones. That picture in itself, is something I highly approve of.

    28. Re:200-line patch by V!NCENT · · Score: 1

      I remember that KateOS had it's own pacthed to hell kernel that would at any time try to utilize the CPU for the full 100%. You open up a text editor and you'll see the CPU spike from 0 to 100 and back, as fast as zzzzzZZZZZZ-BOOM!-zzzzzZZZZ.

      --
      Here be signatures
    29. Re:200-line patch by Eunuchswear · · Score: 1

      All those things are still true.

      Yes, it's a bummer that Nokia have screwed up, but the N900 is still the only game in town if you want to run Linux on a phone.

      --
      Watch this Heartland Institute video
    30. Re:200-line patch by Eunuchswear · · Score: 1

      I'd certainly make use of some of this... but I probably won't be able to unless someone backports it to 2.6.28 due to the damn proprietary graphics drivers.

      They are in user space aren't they? AFAIK there is no closed code in the N900 kernel.

      --
      Watch this Heartland Institute video
    31. Re:200-line patch by Timmmm · · Score: 1

      > the switch from TTY-based grouping to session ID-based grouping.

      All GUI apps have the same session ID, so I don't see how this will affect things at all. Behold:

      thutt@panic:~$ ps -eo session,pid,cmd | grep
        1630 12732 /home/timmmm/Matlab2010b/bin/glnxa64/MATLAB -desktop
        1630 19095 lyx
        1630 30014 /home/timmmm/Projects/lastfm-linux/Lastfm/lastfm-1.5.4.26862+dfsg/bin/last.fm
        1630 30605 gnome-terminal
        1630 29914 /opt/google/chrome/chrome

      So if I do some crazy computation in matlab, or a compilation in an IDE this won't help me one bit.

    32. Re:200-line patch by AvitarX · · Score: 3, Funny

      Doesn't BeOS lack things that one expects from an OS though, like users?

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    33. Re:200-line patch by GooberToo · · Score: 1

      I'm honestly not sure about stock kernels and even that likely varies from manufacturer to manufacturer, but many (most - all) third party roms do use process groups to allow for priority assignment and are heavily tweaked in this regard. This is one of the reasons why many third party roms seem to be more responsive than factory roms.

      While I can't say for sure, I wouldn't be the least bit surprised if this finds its way into android as this type of technology can go a long way toward reducing interface latency. For example, system services and launcher could be in two groups while use applications and services could be in a third. That means the CPU need only divided three ways, and sub-divided from there, rather than shared sixty ways which definitely drives up interface latency.

    34. Re:200-line patch by GooberToo · · Score: 1

      Umm.. a poster above spoke about this patch in terms of Person A and Person B, so I am assuming it's a patch which distributes computing resources in a more fair manner among users accessing the system simultaneously. So, no desktop user will ever notice this as only one user accesses the machine ever. If this is what it is, it is extremely similar to a project I did two semesters back. xD

      It doesn't really have anything directly to do with people. Instead of person A and B, think of it as process group A and B. The A and B can be associated with two difference people or one person and two different processes.

      So to be absolutely clear, most desktop users absolutely will see a difference. Using the traditional example, you can now do a massive compile while listening to music and browse the web without any noticeable effect on music playing and web browsing, all the while the background compile is happily chugging along.

      If we break that example down it looks something like this. Let's assume a compile of four processes and playing music and web browsing each take one process. The old scheduling means that the music player gets one unit of work scheduled out of every six. The same goes for the web browser. On the other hand, the compile gets four work units out of every six. If you only have four CPUs, that means some mix of two processes are always waiting to run. If that's your music player or web browser, you might discern some delay or skipping.

      On the other hand, with process groups associated with sessions, your web browser and music player, each, now see one out of every three units. That more of less means they each get a dedicated CPU some some left over for the compile. Likewise, that means the compile gets a dedicated CPU and whatever the music player and web browser didn't use. That translates into the web browser and music player being able to run 16.3% more frequently and because of cpu affinity distribution is far more likely to experience lower latencies and higher cache hits.

    35. Re:200-line patch by bedouin · · Score: 1

      LOL. Yes, but I'm still sour about its demise. Haiku is my only hope for a BeOS revival.

    36. Re:200-line patch by blair1q · · Score: 1

      Flash? Feh. Barely keeps one core at 50% with hyperthreading turned on.

    37. Re:200-line patch by blair1q · · Score: 1

      That's an application-design problem, not an OS problem. Tell your browser to increase the number of sockets it is allowed to open. The inet stack will take care of queueing them for you. The browser may or may not put them in separate threads to be dealt with on separate cores.

    38. Re:200-line patch by blair1q · · Score: 2

      That's why it's so fast.

    39. Re:200-line patch by blair1q · · Score: 1

      Now that's an interesting wrinkle. How does this scheme really interact with multiple processors and hyperthreading? If I have a 4-core, 2-hyperthread system (8 total effective schedulable CPU resources), and I have 3 processes running in 3 sessions then start 16 processes in another single session, all at the same priority, how are those processes scattered across my 16 hyperthreads when all of them get semaphored to wake up?

      I'm starting to think more that this fix, while not deleterious to any previous system dynamics (other than taking a few extra instructions in each scheduler call), isn't going to change how most people see their machines running. It's more like a solution to a small set of problems. Kind of like how MS Word apps will scroll faster when you're selecting text if you drag the cursor off the bottom of the window and waggle it back and forth. Not sure how that works, but it's got to be something about the mouse interrupts kicking something loose in MS's botched UI. I bet it polls for input to see if you want something other than more scrolling, but if you move the mouse it doesn't have to poll. Some stupid shit like that.

    40. Re:200-line patch by PhrstBrn · · Score: 1

      Agreed. Most of the time it shouldn't make difference. It's more advantageous for the case when somebody or some process spins off 100s of processes, or a server service goes out of control and spins off 1000s of processes. Before it would eat up all the CPU cycles, preventing any of the other critical services from doing anything, and likely crashing the server. Now that out-of-control service has no more resource potential than some other service that's functioning correctly.

      It's not like this patch creates new resources out of thin air, but it sure will help prevent too many process bringing your machine to a halt.

    41. Re:200-line patch by AvitarX · · Score: 1

      I should clarify that i mean user accounts, not users of the OS.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    42. Re:200-line patch by RobbieThe1st · · Score: 1

      I'm not sure, but there's got to be -some- reason the heavily-modified 3rd party kernels are all based on the same version, especially when they had to backport some extra features to make it work.
      I -heard- that it was graphics drivers, but I'm not sure - It's definitely -something- though.

    43. Re:200-line patch by Eunuchswear · · Score: 1

      There are no proprietary kernel drivers in the N900. This means that it is possible to upgrade the kernel, if someone will have enough motivation and time for porting some things that are missing from mainline kernel.

      http://www.forums.internettablettalk.com/showpost.php?p=559964&postcount=2

      --
      Watch this Heartland Institute video
    44. Re:200-line patch by Junta · · Score: 1

      most desktop users absolutely will see a difference...you can now do a massive compile

      I stand by my point. *Most* desktop users aren't doing that. Chrome is probably the most 'mainstream' application that would produce a potentially busy large process group depending on tab count, but on the other hand they are genreally only interacting with that application at the time.

      This is not to take away how much this change just makes sense and how much it can do for certain cases, but the way people talk it up sets expectations way too high.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  4. Re:A now untrusted source of information by neokushan · · Score: 1

    I guess you could argue that Linux itself isn't an OS but rather Operating Systems are built using the Linux codebase.
    I wouldn't, though.

    --
    +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
  5. Re:A now untrusted source of information by blair1q · · Score: 2, Insightful

    he could argue that making the kernel faster makes the OS faster

    which is what the quote said

  6. Re:Enough of this! by sslayer · · Score: 2

    You mean like LKM, which has existed for, erm, like forever?

  7. Re:A now untrusted source of information by Anonymous Coward · · Score: 1

    No, it's sloppy. The unclear reference is "the open source operating system". The author either writes "the Linux kernel" to mean "the kernel of the Linux operating system", in which case the reference is clear but wrong, or he means "the kernel called 'Linux'", which is correct but leaves the "the" in "the open source operating system" unclear.

    This display of GNU/pedantry was brought to you by the conglomerate of posters known as AC.

  8. Re:WOW ! SERIOUSLY ? Windows is at VERSION SEVEN ! by blair1q · · Score: 1

    see what i mean about the value of anonymity?

  9. Re:Enough of this! by Jon+Stone · · Score: 5, Funny

    Is that you, Tanenbaum?

  10. Re:WOW ! SERIOUSLY ? Windows is at VERSION SEVEN ! by Anonymous Coward · · Score: 1

    First: this is only the kernel. Ubuntu is on 10.10 (11.04 isn't far off), so that's a better comparison, and by that Ubuntu is a hell of a ways ahead of Windows, and it hasn't even been around as long!

    Second: The NT Kernel in Windows 7 is only 6.1, and that's completely different version numbers than Linux uses. You could say that this is more like version 50 of the Linux kernel (probably beyond that).

    Third: I'd rather use a kernel that was so good it never needed to surpass 2.6 than one that had so many problems it had to elevate to version 6 or even 6.1.

    Last: Obviously troll, but I'm bored...

  11. Misleading article by Edmund+Blackadder · · Score: 5, Insightful

    It is great news that the Linux kernel performance keeps improving, and nowadays you can get the fastest performing commonly used OS for free. But I have to point out that the way the slashdot summary was written is misleading. The slashdot summary has the following quote:

    '"This patch series was both controversial and experimental when it went in, but we're very hopeful of seeing speedups," James Bottomley, distinguished engineer at Novell said. "Just to set expectations correctly, the dcache/path lookup improvements really only impact workloads with large metadata modifications, so the big iron workloads (like databases) will likely see no change. However, stuff that critically involves metadata, like running a mail server (the postmark benchmark) should improve quite a bit."'

    If you read the actual article you will notice that this quote refers only to the RCU portion. Other aspects like transparent huge pages are not controversial and they will improve database performance.

    1. Re:Misleading article by Megaweapon · · Score: 1

      But I have to point out that the way the slashdot summary was written is misleading.

      You must be new.

      --
      I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
  12. Re:YOUR point's taken, but his? Come on... apk by blair1q · · Score: 1

    You have to multiply the vulnerability by the number of bad-actors attempting to exploit it to determine how vulnerable it makes you.

    So, more Windows computers browsing the web (by a factor of like a billion, man) means more black-hats will target Windows computers. Makes Linux computers comparatively safer from that sort of annoyance.

    Not that I care. I use both and deal with what comes out of either. They both find ways to annoy several times a month, they just have different excuses ("oh i have to support billions of users!", "oh i have to be developed by random unpaid wannabes"). Makes one want to use smartphones for everything, but that has its foibles ("oh i have a tiny little screen and nobody designs webpages that tall and narrow").

  13. A kernel for today's world by diegocg · · Score: 4, Interesting

    B.A.T.M.A.N. mesh protocol (which helps to provide network connectivity in the presence of natural disasters, military conflicts or Internet censorship)

    Looking at what happened recently in Japan, Lybia or Egypt...it seems a feature that I would like to have in my system. Just in case...

    1. Re:A kernel for today's world by Compaqt · · Score: 1

      Unfortunately, if you saw the picture of the rebel media center in Benghazi at BoingBoing, those guys are using Windows XP. How can we promote free and legal alternatives to free and illegal (cheap XP CDs)?

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    2. Re:A kernel for today's world by snadrus · · Score: 1

      They want "what the rest of the world uses" == "what's been advertised". Promote it with CDs, Google Trends for Linux vs Microsoft Windows (especially if excluding the US). Legal doesn't matter to a country in revolution, but freedom (knowing it's not a spy/sabotage platform) via peer-review does.

      --
      Science & open-source build trust from peer review. Learn systems you can trust.
  14. A whole lot faster? by kwerle · · Score: 2

    What does that mean? Is it like 20% faster? I dunno - I think 5% would be a lot faster. But .5% or less? what are we talking about, here?

    1. Re:A whole lot faster? by Ant+P. · · Score: 1

      THP makes memory-heavy stuff anywhere up to 5% faster based on some quick testing I did with it on folding@home.

    2. Re:A whole lot faster? by kwerle · · Score: 1

      THP makes memory-heavy stuff anywhere up to 5% faster based on some quick testing I did with it on folding@home.

      5% is pretty impressive for a kernel update.

  15. Good detailed summary by tick-tock-atona · · Score: 3, Informative

    The H Open:
    http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-38-1205467.html

  16. Minor Update by Anonymous Coward · · Score: 1, Funny

    2.6.36 to 2.6.38? Tell me when there's an actual update.

    (Fair turnaround for the bitching about Apple's "minor" 10.x.y updates.)

    1. Re:Minor Update by BuddaLicious · · Score: 1

      Fair Turnabout implies the situation is the same, but turned around. That is not the case here. Difference being that Linus is NOT out there behind a podium telling a crowd of people that "this is best brand New Version of Linux EVER, and it's totally different and better"
      Without a figurehead idiot trumping up this update its just not the same thing. You can't really blame the Linux community for being interested in a update to their software can you? It's not like they are making grandiose claims or holding press large press conferences that this is "the next big thing" (like Apple and others routinely do for their basic updates).

  17. A Marketing Coup! by rueger · · Score: 1

    Transparent Huge Pages

    It doesn't matter what that is*, it's got "Buy Me!" written all over it!

    OSX might have the Dock, and Windows might be up to version 7, but my Ubuntu machine has Transparent Huge Pages!


    *save your breath, I actually looked it up.

    --
    Three Squirrels
    1. Re:A Marketing Coup! by Mr+Z · · Score: 1

      I have 16GB RAM in my 64-bit machine at home. I actually look forward to THP, since any process that actually benefits from that much RAM would also benefit from THP if it isn't already using hugetlbfs. As far as I can tell, hugetlbfs almost never gets used, so that means just about any process that I'd run that needs that much RAM would benefit from THP.

      The other day I edited a page-sized full color scan in The Gimp at 600 DPI without swapping. That was actually pretty cool. That's an app that'd benefit from THP.

      --
      Program Intellivision!
    2. Re:A Marketing Coup! by Compaqt · · Score: 1

      Would you mind sharing the specs on your rig? I might be needing to buy a new system this year.

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    3. Re:A Marketing Coup! by Fallingcow · · Score: 1

      The Dock is the opposite of a selling point.

      Wait, I take that back--it does look awesome on a demo machine, so I guess it helps sales after all.

    4. Re:A Marketing Coup! by Mr+Z · · Score: 1

      It wasn't anything too special. I built a pretty basic Phenom II x4 box. Here's a cut/paste from my Newegg receipt, minus prices.

      • 1 x CASE NZXT| PHAN-001WT RT
      • 1 x PSU ROSEWILL|RBR1000-M 1000W RT
      • 4 x MEM 4G|CORSAIR XMS CMX4GX3M1A1600C7
      • 1 x HD 1.5T|WD 7K 64M WD1501FASS % - OEM
      • 1 x CPU AMD|PH II X4 965 3.4G AM3 RT
      • 1 x MB GIGABYTE|GA-880GA-UD3H R

      Now, I didn't buy a fancy video card. That total rig, though, cost me less than $1K and that was a few months ago.

      --
      Program Intellivision!
  18. Re:A now untrusted source of information by anon37 · · Score: 5, Funny

    Incorrect. The term "operating system" refers to software written by Richard Stallman and GNU. The "Linux kernel" is not "the heart" of anything! It is merely a component in the Emacs software suite.

  19. As always, XKCD seems apropos by mhotchin · · Score: 1, Funny

    http://xkcd.com/619/

    1. Re:As always, XKCD seems apropos by jabjoe · · Score: 2

      Go on then, I'll bite.
      That's not Linux's problem, it's Adobe's and the graphics card manufacturers. Loads of reimplimenting of closed stuff needs to happen for it to be Linux's fault. (That's Linux as a platform, not as just a kernel) With Gallium/DRM/KMS/Wayland/etc and HTML5 hopefully it will be Linux's problem and will all go away nicely. Having said all that, works ok for me now with the closed Flash player and the closed NVidia drivers. It's just unpalatable (and you are left in the slow lane of X developments, oh and booting is ugly and you can't switch virtual tty safely or fast).

    2. Re:As always, XKCD seems apropos by bloodninja · · Score: 1

      It _is_ Linux's problem. It might not be Linux's fault, but it is Linux's problem.

      --
      Lock the wife and the dog in the boot of the car.
      Return one hour later.
      Who's happy to see you?
    3. Re:As always, XKCD seems apropos by Threni · · Score: 1

      To be fair, with 2,048 CPUs, Flash will probably be running vaguely acceptably.

  20. Re:A now untrusted source of information by Daniel+Phillips · · Score: 1

    I guess you could argue that Linux itself isn't an OS but rather Operating Systems are built using the Linux codebase.
    I wouldn't, though.

    And you would be wrong. Crack any textbook on operating system design and you will learn immediately that by "operating system" knowledgeable people mean "the kernel".

    Does this make a joke of Apple calling FreeBSD "iOS" and Google calling Linux "Android"? Why yes it does, but shush don't them them, they could be terribly wounded.

    --
    Have you got your LWN subscription yet?
  21. Re:YOUR point's taken, but his? Come on... apk by WorBlux · · Score: 5, Informative

    Look at it a little closer.

    In 2010 (last full year)

    Windows 7 - 47 (87% patched)

    Linux 2.6 - 47 (94% patched)

    But look a little deeper and you find something more interesting

    Remote vulnerabilities

    Windows - 55%

    Linux - 9%

    Criticality

    Windows - 6% not, 36% less, 17% moderately, 40% highly.

    Linux - 47% not c, 49% Less, 4% Moderate

    Impact for System Access

    Windows - 47%

    Linux - 1%

    Not all bugs and vulnerabilities are made equal or are equally important. Every program no matter how good, will have bugs, and some bugs will be exploitable. Your comparison is also flawed as 2.6 is much older than windows 7. (By a factor of about 5) Your reasoning is further flawed as a list of of windows vulnerability doesn't include, word, above, acrobat, or IE exploits. which will also add a number of vulnerabilities to a home desktop windows system.

  22. Linux 38 by Anonymous Coward · · Score: 1

    If they are never going to go past 2.6 shouldn't we just start saying Linux 38 is out. Then you could get everyone else to ditch Windows 7 because Linux 38 is like more than 5 times better.

    1. Re:Linux 38 by NotBorg · · Score: 1

      That be version 38 of the 2.6 kernel. If you want a flat single number version, it would be higher than 38, right? Eat kernel shorts Google Chrome!!!!

      --
      I want this account deleted.
  23. Re:Enough of this! by LordLimecat · · Score: 1

    Roll your own kernel, and you can remove drivers you dont want. You can also add whatever patches you want.

  24. Can't wait by Bengie · · Score: 1

    I can't wait until I can switch over from Windows. All I'm waiting for is Direct 3D 11 support and fast stable graphics drivers. When I don't need to dual boot to play my games the way they were meant to be played, then I'm running on over.

    1. Re:Can't wait by snadrus · · Score: 1

      D3D11 has a Gallium state tracker now. Getting Wine using it's another story. Of-course the Gallium drivers are being reverse-engineered for NV & ATI since they won't share spec, code, or blobs, but this kernel & the next both have serious improvements in those areas. I recently got an Intel Sandy-Bridge laptop (i5) since it's got the best open-source video card built-in at the moment. It plays StarCraft 2 nicely in Linux. It doesn't compare to $1000 Windows rigs but was half that price total and plays everything I've found.

      --
      Science & open-source build trust from peer review. Learn systems you can trust.
  25. No Fusion for you by furbearntrout · · Score: 1
    Fucked up free Radeon drivers. Back to Fglrx for now. Crap.

    This release adds support for the AMD Fusion GPU+CPUs

    Only if you want your box to reboot if you try a serious game. Maybe next time.

    --
    Crap. What did the new CSS do with the "Post anonymously" option??
  26. State of SSD support? by jones_supa · · Score: 2

    I'm still curious about SSD support. Yes, TRIM command is supported but is it actually connected to the filesystems? Partition alignment is also a bit of a mystery, but according to some rumors, recent Ubuntu installers get it right.

    1. Re:State of SSD support? by Skapare · · Score: 1

      Proper partition alignment has been a long term issue that was ignored for at least a decade. Now that it is happening, the common alignment (1M, 2048 legacy sectors) might now need to change (2M, 4096 legacy sectors). In a few years, people might even get over the loss of another 2M of dirt cheap disk space (don't forget that we're all going to GPT which has another partition table at the end of the drive).

      --
      now we need to go OSS in diesel cars
    2. Re:State of SSD support? by Skapare · · Score: 1

      Are you assuming that when one does an upgrade, it automatically re-aligns the partition starting points?

      --
      now we need to go OSS in diesel cars
    3. Re:State of SSD support? by sbalneav · · Score: 2

      TRIM support works on recent kernels, and EXT4 filesystems, for me. You just have to make sure you mount with -o discard

  27. Re:.38 in Natty? by xie · · Score: 1

    Now i'm curious if Ubuntu 11.04 aka Natty Narwhal will ship Linux 2.6.38

    According to Natty alpha site it will ... http://www.ubuntu.com/testing/natty/alpha3

  28. Re:A now untrusted source of information by DrXym · · Score: 1

    In an alternate reality Slashdot is only available via an email request and must read through Gnus.

  29. Re:Question: How does it feel to be dissected? LOL by Ginger+Unicorn · · Score: 1

    You forgot to add:

    EARTH HAS 4 CORNER

    SIMULTANEOUS 4-DAY

    TIME CUBE

    IN ONLY 24 HOUR ROTATION.

    4 CORNER DAYS, CUBES 4 QUAD EARTH- No 1 Day God.

    --
    (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
  30. Ketracel White by ThatsNotPudding · · Score: 1

    "Forking is Life."

  31. Getting rid of Dmraid by Zarhan · · Score: 1

    I've been running using dmraid in RAID 5 configuration - I need to use Intel's fakeraid to facilitate dual-booting to Windows. Does this commit

    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9d09e663d5502c46f2d9481c04c1087e1c2da698

    mean that I no longer need to hunt patches for dmraid5 but can just use vanilla kernel from now on?

  32. Punchcard support! by CSMoran · · Score: 1

    http://kernelnewbies.org/Linux_2_6_38 says:
    > Core:
    > - Add hole punching support to fallocate() (commit)

    Good to see the efforts towards backward compatibility, I often wondered why punchcard support was lacking in previous releases.

    --
    Every end has half a stick.
  33. Re:Switched back to Windows 7 by Turiko · · Score: 1

    I've had the opposite happen quite often with older pc's - drivers for windows xp that should work are buggy, no drivers for 7. Put on ubuntu, it works :).

  34. Re:A now untrusted source of information by Knuckles · · Score: 1

    When people refer to the "Windows OS", they are really talking about NTOSKRNL.EXE? I don't think so.

    --
    "When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
  35. Re:Off topic replies NEED NOT APPLY by Ginger+Unicorn · · Score: 1

    You're delicious.

    --
    (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
  36. Re:.38 in Natty? by drinkypoo · · Score: 1

    More to the point it already has and it works OK, I will be moving to natty soon. I finally gave up on vmware and installed XP to a disk on my PC (last time I tried I got black screens reliably, installed from the same CD that I got black screens from before, no BIOS updates since... OMGIGABYTEWTFBBQ.) I can only imagine that a recent nVidia driver for Linux did something to my GT240 that fixed the problem. Microcode update? Anyway vmware player not working on natty was the last reason I had to stick with Maverick, so I anticipate making the upgrade very soon. I need to install much more software first.

    I've booted natty (on 2.6.38) from an OCZ Rally2 16GB and it seemed fairly peppy. All major functionality seems to work except that I inexplicably have two network managers and I can't seem to remove them. Have done zero homework or even snooping of gconf since I have been messing with my new XP install (which bluescreened with STOP c000021a 0xc0000135 after the first round of updates, probably due to AMD chipset drivers, didn't load them again of course on the reinstall. upgrade-in-place failed of course. Too late to install Watson on that go 'round. Now I have a backup of a working install :p

    It's been a couple days since I updated natty so I've chroot'ed in from maverick (I kinda whacked my maverick install on the bleeding edge of PPAs, compizfail) and I'm updating it again. Perhaps I'll give it a reboot in a moment.

    A windows utility bundled with the system claimed I was getting CPU idle power down to about 10 watts from 30. Outstanding. I wonder what it's like in Linux.

    P.S. All hail debootstrap. All hail debian!

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"