No announcement yet.

The ~200 Line Linux Kernel Patch That Does Wonders

  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by misiu_mp View Post
    Interesting to know what scheduling tricks do they use for the UI. Is it a generic solution or could it be just one UI process with higher priority?
    A lot of things, realy. It's not some genious algorithm, though. It is done in the kernel, but managed from userspace. A sort of avarge on which priority a process has and what the physical user is doing on the screen. So for example if the user maximises a window, then the maximised window app gets more priority. That sort of thing.

    Watch the Vista kernel dev interview on channel9. Windows 7 is actualy Windows Vista but the UI gets some slice of what the user is doing trick, combined with optimizations of the UI app itself.

    Don't forget that Windows tightly integrates the UI with the kernel, where on Linux it is just an afterthought with, that currently happens to have its Gallium3D driver framework partialy into the Linux kernel now, but there is no kernelspace<->userspace management voodoo going on


    • Quote from Lennart Poettering:

      ere's my super-complex patch btw, to achieve exactly the same thing
      from userspace without involving any kernel or systemd patching and
      kernel-side logic. Simply edit your own ~/.bashrc and add this to the end:

      if [ "$PS1" ] ; then
      mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
      echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks

      Then, as the superuser do this:

      mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
      mkdir -m 0777 /sys/fs/cgroup/cpu/user
      Original post:

      This sounds easier to folks having issue compiling the kernel.


      • Read more on the original post, it seems that the responsiveness only exhibits when you have a huge process running in the terminal.

        Quote from Lennart Poettering:
        Heck, the patch wouldn't even have any effect on my machine (and I am
        hacker), because I tend to run my builds from within emacs. And since
        emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own
        scheduling group.


        • I think OSX does a similar thing with it's apps. This isn't based on any technical knowledge of it but from rather brief usage of it over a period. One thing I noticed is that OSX seems to give the current app that the user is using more priority than other OSs do. With some apps running in the background I noticed they tended to suffer quite noticably while the app in focus ran just fine.


          • Gentoo Linux users have backported this patch to kernels and 2.6.36:



            • Originally posted by Michael View Post
              Jeg er ikke fra Sverige, men som Skandinavia landene.

              [And am bad with speaking Swedish but slightly less bad with Norwegian , but you all seem to know all the scandic languages due to the similarities ]
              Heh, well actually I can't pride myself with knowing finnish, unless 'perkele' counts, oh and of course 'olen t?ss?' which means 'you are here', which can be very important information when you are drunk on a ferry and trying to find your cabin

              Originally posted by devius View Post
              How about you finnish/swedish/norwegian-speaking guys start including subtitles in the posts so the rest of us know what you're talking about. Or do I have to start insulting everyone in portuguese?
              Trust me, you're not really missing out on anything


              • 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



                • Thank you, Marco for detailed information.

                  So with systemd it's not needed to patch kernel now?
                  What's the oldest kernel that did get cgroups that systemd will benefit from it?


                  • Originally posted by xeros View Post
                    Thank you, Marco for detailed information.

                    So with systemd it's not needed to patch kernel now?
                    What's the oldest kernel that did get cgroups that systemd will benefit from it?
                    With latest systemd (today commits) you don't need to patch kernel: systemd solution is alternative to Mike Galbraith patch and achieves the same goal (isolating tasks in cpu groups by user session using libpam-systemd). I think putting the things together will cause some mess.

                    As far as I know all the kernel with cpu cgroup are complaiant with systemd. But systemd requires at least
                    • cgroup mounted on /sys/fs/cgroup (i dont know which commit is in which kernel, perhaps not even in 2.6.36, but easily to backport);

                    To work at best kernel needs
                    • a little patch fixing bug concerning moving tasks accross cgroups;



                    • Sorry, I forgot the announce of new systemd features: