Announcement

Collapse
No announcement yet.

The Linux 2.6.36 Kernel Is Now Out There

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Linux 2.6.36 Kernel Is Now Out There

    Phoronix: The Linux 2.6.36 Kernel Is Now Out There

    The Linux 2.6.36 kernel is now out there on the Internet. After an unexpected delay and some other slowdowns in the 2.6.36 development cycle, Linus tagged the 2.6.36 kernel this afternoon...

    http://www.phoronix.com/vr.php?view=ODY5NA

  • #2
    I'm reasonably sure the heavy I/O responsiveness patches are already in 2.6.36. I used one of the .36-rc's and it was phenomenal with large file operations.

    Comment


    • #3
      Originally posted by etnlWings View Post
      I'm reasonably sure the heavy I/O responsiveness patches are already in 2.6.36. I used one of the .36-rc's and it was phenomenal with large file operations.
      Not all of them, the more untested were held back for 2.6.37.

      Comment


      • #4
        No fanotify!

        Originally posted by phoronix View Post
        Phoronix: The Linux 2.6.36 Kernel Is Now Out There

        The Linux 2.6.36 kernel is now out there on the Internet. After an unexpected delay and some other slowdowns in the 2.6.36 development cycle, Linus tagged the 2.6.36 kernel this afternoon...

        http://www.phoronix.com/vr.php?view=ODY5NA
        Fanotify system calls were pulled at the last minute over ABI concerns. See the release announcement.

        Comment


        • #5
          Originally posted by Xake View Post
          Not all of them, the more untested were held back for 2.6.37.
          Well that will be interesting, considering current performance (on relatively old hardware, even). I stand corrected.

          Comment


          • #6
            Oh God please desktop responsiveness patches.

            Comment


            • #7
              This seems to be the topic of the day, so here it goes once again:

              Desktop responsiveness patches FTW \m/

              Comment


              • #8
                typo: debuging should be debugging

                Comment


                • #9
                  I have been a Linux junky for many years. But recently I came across a data point which really baffled me for and put shameful dent in my pride of Linux.

                  At our company, one of the things that was forced down our throats were laptops with Windows 7 running. We had to use VMs to run Linux for our development.

                  Being a Linux zealot, I reversed the roles. Ran Linux on host and Windows 7 in VM. I noticed that just one Windows 7 VM running, with 1GB given to it, a project build (which is largish) can make the desktop completely unresponsive: mouse freezes, desktop can't be changed, Windows7 VM doesn't refresh its window etc. And this is with 2.6.36-rc7.

                  Reverse the roles, run 3 Linux VMs inside Windows 7 with 1GB of RAM each. Build the same project inside any of those VMs and everybody (the host as well as all the VMs) keeps chugging along nicely. And surprisingly, the build (which is pretty linear single thread) inside VM finished faster.

                  That hurt bad! Why is it that we can't find this bottleneck and fix it after so many years?

                  Comment


                  • #10
                    I have been a Linux junky for many years. But recently I came across a data point which really baffled me for and put shameful dent in my pride of Linux.

                    At our company, one of the things that was forced down our throats were laptops with Windows 7 running. We had to use VMs to run Linux for our development.

                    Being a Linux zealot, I reversed the roles. Ran Linux on host and Windows 7 in VM. I noticed that just one Windows 7 VM running, with 1GB given to it, a project build (which is largish) can make the desktop completely unresponsive: mouse freezes, desktop can't be changed, Windows7 VM doesn't refresh its window etc. And this is with 2.6.36-rc7.

                    Reverse the roles, run 3 Linux VMs inside Windows 7 with 1GB of RAM each. Build the same project inside any of those VMs and everybody (the host as well as all the VMs) keeps chugging along nicely. And surprisingly, the build (which is pretty linear single thread) inside VM finished faster.

                    Laptop has 4GB of RAM and Windows 7 (32-bit) sees only 3.4GB while Linux sees all 4GB of it, so technically Linux is working with more RAM.

                    That hurt bad! Why is it that we can't find this bottleneck and fix it after so many years?

                    Comment

                    Working...
                    X