Announcement

Collapse
No announcement yet.

The ~200 Line Linux Kernel Patch That Does Wonders

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

  • Your server going down in ten, nine, eight ...

    Comment


    • Welcome back, Linux! Prior to this patch, on 2.6.36 a simple rsync of some multi-gigabyte files over a 6-disk raid on a core i7 with 12GB ram would take the desktop down. Audio stutters, compiz windows fading out due to delays, and unable to start a tomcat server in eclipse due to the default 45 second startup timeout.

      Post patch on 2.6.37 results doing the same rsync as before, compiling the kernel with a -j30, playing audio, and launching tomcat from eclipse and no stutters or nasty delays!!!! The load hit about 40, and the system kept running without any extreme delays!

      Those wondering if the patch helps with the io issues, I'd have to say yes. The only kernel change I did from the 2.6.36 was to enable the automatic process group scheduling. You could see the throughput go up and down during the rsync. This sure beats having to worry about ionice and bandwidth limiting the rsync process just to avoid desktop issues.

      Thanks for the simple yet extremely helpful patch.

      Comment


      • FYI: this patch has already been incorporated into openSUSE's Head kernel repo:

        https://features.opensuse.org/310843

        Done. In kernel:HEAD repo, only for -desktop flavour.
        http://download.opensuse.org/reposit...openSUSE_11.3/

        Comment


        • Haha Windows and a shiny console environmnt :rollryes:

          I saw it on XP at my school years ago. Maybe check YouTube?

          Also I might have wrongly interpreted the scheduling voodoo as my knowledge was extremely limited compared to what I know now. What I know now is even limited

          I can't search for the video on youtube for you because I on my mobile phone right now.

          Comment


          • Originally posted by zicada View Post
            This patch doesn't apply to IO loads at all, only CPU. It is currently being discussed to add a similar patch to the kernel for automatically using cgroups for IO loads as well.

            What's important to realize is that it was possible to do what this patch does for quite a while using cgroups. The issue has been that no distros really have made any use of it.
            BS

            did you even re-compile your kernel ?

            when enabling the autogroup option and cgroups for CFQ - which you're asked for the responsibility "feels" much better

            also: my apps seem to close and open noticably faster - it might be only 1-2 seconds less but it's noticable in my everyday workflow

            Comment


            • Originally posted by kernelOfTruth View Post
              BS

              did you even re-compile your kernel ?

              when enabling the autogroup option and cgroups for CFQ - which you're asked for the responsibility "feels" much better

              also: my apps seem to close and open noticably faster - it might be only 1-2 seconds less but it's noticable in my everyday workflow
              Placebo, unless you open all those apps from a terminal, AND have a task running that tries to eat up all your resources. Why do people think this patch is some kinda magical thing ?

              Which of the apps you're opening are attached to TTYs ?

              I recommend actually reading the thread discussing this patch before you go around calling my prev. post BS.

              Comment


              • Excellent points.

                Ultimately the kernel is there to accommodate different user-space cases, with sane defaults, options and all.

                The two sides of the whole (i.e us all) need to cooperate; and they do.

                Here (the optional) systemd represents users-space tools for adjusting system/kernel behaviour "on-the-fly" and with higher level of granularity.

                Still, the ability to configure kernel-space behaviour (at the time of compilation and without specific user-space tools) will be expected.

                All the eyeballs are there so... bring on 2011! (the year when Linux... servers take over the desktop!)


                Originally posted by marco View Post
                Update:
                After the fight Linus vs Lennart (kernel vs user) at the end Lennart implemented the same thing the patch does in systemd (check out latest commit).

                If the requisite is :
                The latency improves only by isolating tasks in containers (cgroups)
                In think Systemd acheives this in the right way:
                1. all is configurable (with pam-systemd you can choose whatever controller you like (cpu, memory, block by which every user isolate his tasks);
                2. systemd knows better what is a session (the kernel doesn't even know it);
                3. anytime, you can see what is going on (do a pstree on /sys/fs/cgroup)

                Comment


                • I don't know if anybody has seen this but its an alternative to the 200 line patch that does the same thing. Just add 4 lines to your bashrc and do two commands on the command line.

                  http://www.webupd8.org/2010/11/alter...nel-patch.html

                  benchmarks of both methods

                  http://lkml.org/lkml/2010/11/16/392

                  Comment


                  • Originally posted by misGnomer View Post
                    Excellent points.

                    Ultimately the kernel is there to accommodate different user-space cases, with sane defaults, options and all.

                    The two sides of the whole (i.e us all) need to cooperate; and they do.

                    Here (the optional) systemd represents users-space tools for adjusting system/kernel behaviour "on-the-fly" and with higher level of granularity.

                    Still, the ability to configure kernel-space behaviour (at the time of compilation and without specific user-space tools) will be expected.

                    All the eyeballs are there so... bring on 2011! (the year when Linux... servers take over the desktop!)
                    This patch is really not supposed to be there! Lennart gave a 6 line script that does exactly the same and Linus said Mike developed the patch the same way.

                    Linus' concern is that this behaviour is not default, but it should not be default if it is just a policy. I think that's the whole point those guys are arguing about. I do not think this patch is appropriate personally. Go with BFS. BFS rules.

                    Comment


                    • Originally posted by glasen View Post
                      Not necessarily. I've successfully applied the patch to a vanilla 2.6.36 kernel. The only thing i had to do was to correct two small errors.

                      If someone is interested, here is the patch for kernel-version 2.6.36 :

                      sched_automated_per_tty_task_groups_2.6.36.patch
                      Thank you for the patch. It applied cleanly and I'm compiling now.

                      Comment


                      • Originally posted by Obscene_CNN View Post
                        I don't know if anybody has seen this but its an alternative to the 200 line patch that does the same thing. Just add 4 lines to your bashrc and do two commands on the command line.

                        http://www.webupd8.org/2010/11/alter...nel-patch.html

                        benchmarks of both methods

                        http://lkml.org/lkml/2010/11/16/392
                        Exactly. I posted the same 2 pages back.

                        When you translate a 6 line script to a 200 line kernel patch, it suddenly doesn't seem exciting anymore does it.

                        Comment


                        • Just a thought,

                          Is there a way to use this patch to give an app that runs in a TTY priority over the GUI? In some cases people do have mission critical apps.

                          Comment


                          • Originally posted by marco View Post
                            Update:
                            After the fight Linus vs Lennart (kernel vs user) at the end Lennart implemented the same thing the patch does in systemd (check out latest commit).

                            If the requisite is :
                            The latency improves only by isolating tasks in containers (cgroups)
                            In think Systemd acheives this in the right way:
                            1. all is configurable (with pam-systemd you can choose whatever controller you like (cpu, memory, block by which every user isolate his tasks);
                            2. systemd knows better what is a session (the kernel doesn't even know it);
                            3. anytime, you can see what is going on (do a pstree on /sys/fs/cgroup);
                            I would like to point out that this great work comes from the following history:
                            • Con Kolivas sd scheduler;
                            • Ingo Molnar cfs scheduler;
                            • Ingo introduce Paul Menage cgroups in cfs scheduler;
                            • Mike Galbraith in-kernel autogrouping based on cfs-cgroup scheduler;
                            • Lennart Pottering autogrouping in user-space (systemd);

                            This is a great story of success.
                            Thanks to all people involved

                            Marco
                            Thanks for summarizing it Marco.

                            I totally agree with the systemd solution and I am looking forward to testing it. Hopefully this will be availible in package updates for RHEL6(?).

                            It would be interesting if we could set a approximate date on the history bullets?

                            Comment


                            • can someone backport this patch to the lucid kernel 2.6.32-22 ?

                              Comment


                              • This is a very stupid thread. You could do this with cgroups long ago (for cpu, disk and memory as well). All you need to do is to create wrappers for your favorite (or hated) programs to isolate their resource usage behavior. Read up on this:

                                http://broadcast.oreilly.com/2009/06...-projects.html

                                And yes, some people here are right. This is not going to magically speed up your program loads or make gcc compile your source faster (if at all, it will be a slow down in throughput: Ingo says its around 5% overhead).

                                Comment

                                Working...
                                X