Announcement

Collapse
No announcement yet.

Linux 2.6.37-rc1 Kernel Is Here; Can Build Without BKL

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

  • Linux 2.6.37-rc1 Kernel Is Here; Can Build Without BKL

    Phoronix: Linux 2.6.37-rc1 Kernel Is Here; Can Build Without BKL

    As anticipated, the 2.6.37 merge window closed yesterday and the first release candidate for the Linux 2.6.37 kernel is now available. Major changes that were pushed into the Linux 2.6.37 kernel include support for building the kernel without the Big Kernel Lock (BKL), many graphics DRM improvements, and more of the responsiveness patches...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Would it be possible to make a benchmark for PTS to test how the perceived responsiveness of the desktop has changed?

    Comment


    • #3
      Originally posted by phoronix View Post
      Major changes that were pushed into the Linux 2.6.37 kernel include support for building the kernel without the Big Kernel Lock (BKL)
      This is HUGE!

      Comment


      • #4
        Here is some background for illustrating what it's all about: http://kerneltrap.org/Linux/Removing...g_Kernel_Lock2

        This effort has been going on for 8 years now!

        (edit limit bites again)

        Comment


        • #5
          ..the various dependencies of the lock are lost in the haze of 15 years of code changes, "all this has built up to a kind of Fear, Uncertainty and Doubt about the BKL: nobody really knows it, nobody really dares to touch it and code can break silently and subtly if BKL locking is wrong."
          Reminds of the Dilbert where they hypnotize Wally back to his younger/Cobol days cause he's the only one that can fix the mainframe.

          Comment


          • #6
            I was worried about btrfs because there didn't really happen anything and no commits for the past 2-3 months it seemed, but I see there's lots of stuff in the .37rc1 kernel, so all is well. I see that someone from RedHat is on the ball with btrfs also now.

            Comment


            • #7
              Will a kernel w/o Big Kernel Lock itself result in any noticeable performance difference for a Desktop user?

              What kind of functionality is currently tied to V4L? Webcams?

              How does BKL apply to V4L2?

              Comment


              • #8
                I think the problem is that V4L manually locks and unlocks the BKL, which will not work if BKL is not used. It will have to be ported, like most core subsystems have been already.

                I don't know if it will result in performance improvement, but I believe that this was not the major motivation. The major motivation is that it was one big scary voodoo which nobody really understood anymore.

                Comment


                • #9
                  Is there any progress with Linux responsiveness problems
                  as reported in:


                  Binary package hint: linux-source-2.6.22 When compared with 2.6.15 in feisty, heavy disk I/O causes increased iowait times and affects desktop responsiveness in 2.6.22 this appears to be a regression from 2.6.15 where iowait is much lower and desktop responsiveness is unaffected with the same I/O load Easy to reproduce with tracker - index the same set of files with 2.6.15 kernel and 2.6.22 kernel and the difference in desktop responsiveness is massive I have not confirmed if a non-tracke...

                  Comment


                  • #10
                    Originally posted by pingufunkybeat View Post
                    I don't know if it will result in performance improvement, but I believe that this was not the major motivation. The major motivation is that it was one big scary voodoo which nobody really understood anymore.
                    There were certain places where i think it limited performance, but whether that will be noticeable by a desktop user I'm not sure. I think it was important for things like RT linux as well. The real gain is that now driver and subsystem maintainers can work in their code without having to worry about messing up the BKL in weird ways for everyone else that is using it across the whole kernel.

                    Comment

                    Working...
                    X