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...

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

  • #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:

                  https://bugzilla.kernel.org/show_bug.cgi?id=12309
                  https://bugs.launchpad.net/ubuntu/+s...ux/+bug/131094

                  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


                    • #11
                      whats the difference between BKL and nonBKL ?
                      any charts? tests? something?

                      Comment


                      • #12
                        Originally posted by NomadDemon View Post
                        whats the difference between BKL and nonBKL ?
                        any charts? tests? something?
                        Are you asking for an explanation or benchmarks?

                        If you want an explanation, wikipedia under "giant lock" has an explanation that might help you understand it better.

                        Comment


                        • #13
                          iam not native english, i already reed giant lock, but dont understand anything [nothing seems to be more clear]

                          both, benchmarks and explanations

                          Comment


                          • #14
                            Did anybody tried compiling without Big Kernel Lock, this is what I get:
                            Code:
                              CHK     include/linux/version.h
                              UPD     include/linux/version.h
                              CHK     include/generated/utsrelease.h
                              UPD     include/generated/utsrelease.h
                              HOSTCC  scripts/kallsyms
                              CC      scripts/mod/empty.o
                              HOSTCC  scripts/mod/mk_elfconfig
                              MKELF   scripts/mod/elfconfig.h
                              HOSTCC  scripts/mod/file2alias.o
                              HOSTCC  scripts/mod/modpost.o
                              HOSTCC  scripts/mod/sumversion.o
                              HOSTCC  scripts/pnmtologo
                              HOSTCC  scripts/conmakehash
                              HOSTCC  scripts/bin2c
                              HOSTLD  scripts/mod/modpost
                              CC      kernel/bounds.s
                              GEN     include/generated/bounds.h
                              CC      arch/x86/kernel/asm-offsets.s
                            In file included from /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/suspend_64.h:10:0,
                                             from /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/suspend.h:4,
                                             from arch/x86/kernel/asm-offsets_64.c:20,
                                             from arch/x86/kernel/asm-offsets.c:4:
                            /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/i387.h: In function ‘irq_ts_save’:
                            /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/i387.h:324:2: error: implicit declaration of function ‘kernel_locked’
                            make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
                            make: *** [prepare0] Error 2
                            [root@phenon linux-2.6.37-rc1]# make
                              CHK     include/linux/version.h
                              CHK     include/generated/utsrelease.h
                              CC      arch/x86/kernel/asm-offsets.s
                            In file included from /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/suspend_64.h:10:0,
                                             from /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/suspend.h:4,
                                             from arch/x86/kernel/asm-offsets_64.c:20,
                                             from arch/x86/kernel/asm-offsets.c:4:
                            /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/i387.h: In function ‘irq_ts_save’:
                            /usr/src/linux-2.6.37-rc1/arch/x86/include/asm/i387.h:324:2: error: implicit declaration of function ‘kernel_locked’
                            make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
                            make: *** [prepare0] Error 2
                            [root@phenon linux-2.6.37-rc1]#

                            Comment


                            • #15
                              Originally posted by NomadDemon View Post
                              iam not native english, i already reed giant lock, but dont understand anything [nothing seems to be more clear]

                              both, benchmarks and explanations
                              A lock is a synchronization primitive. Basically you place it around blocks of code, and then it becomes impossible for 1 thread to enter the block until the first has exited. The idea is to keep 1 thread from deleting or modifying some shared data before another thread has finished using it. In a userspace program that is only an issue for multi-threaded applications. In the kernel, there are all sorts of threads, events, and hardware interrupts that can cause an issue.

                              A long time ago, devs originally create 1 large lock and used it everywhere in the kernel. That was simple to do, because essentially grabbing the lock switched all the code inside into a single-threaded mode. But it has issues with scalability - you want as many different threads as possible able to work. There's no reason the memory subsystem and the Ext4 filesystem should both be blocking each other. So the solution is to create 2 locks, one for each section. The complication is that so much complicated code had come to rely on the single lock that it was almost impossible to predict the behavior of the kernel when you messed with that global lock. So people have been slowly going through section by section of the kernel to try and factor out what codes needs to share the same lock and what code can be separated out. A lot of the code under the global lock didn't even need to be, and was just there because the original coder thought it might be an issue.

                              So I'm not really sure how benchmarks will change. It will definitely increase the scalability of anything that likes to hit a bunch of kernel code. But on the other hand, this has been going on piece by piece for many years. So a lot of the benefits were already done and in previous kernels.

                              Comment

                              Working...
                              X