Announcement

Collapse
No announcement yet.

The ~200 Line Linux Kernel Patch That Does Wonders

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

  • Originally posted by HokTar View Post
    Well, the thing is that I don't compile stuff, but still sometimes I have huge I/O loads and then even the music stops and my cursor barely moves. If this could help in such cases that would be awesome.

    I do not run the demanding stuff in terminal, so maybe nothing will change for me. That would be a pity...
    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.

    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.
      Then I really don't get it. Why do people complain about bad responsiveness? I have no problems whatsoever if it's not I/O related.
      My laptop is pretty fast and responsive even though I run Boinc (Einstein@home) all the time.
      I mean I've never felt any difference if I paused Boinc, so no problems with the scheduler. Or is it just because Boinc has a constant "lowest" priority?

      Am I missing something?

      Comment


      • Originally posted by HokTar View Post
        Then I really don't get it. Why do people complain about bad responsiveness? I have no problems whatsoever if it's not I/O related.
        My laptop is pretty fast and responsive even though I run Boinc (Einstein@home) all the time.
        I mean I've never felt any difference if I paused Boinc, so no problems with the scheduler. Or is it just because Boinc has a constant "lowest" priority?

        Am I missing something?
        Well Boinc is running 64 processes at once as in the test case here.

        The article on OMG Ubuntu about this is a bit of a joke, it makes it sound like this is some magic patch that makes Linux run 10 times faster normally.

        Comment


        • It is the IO load that is/was the problem in Linux. The ability of (an) IO-bound process(es) to starve a CPU-bound process when the latter needs to access a little of IO. You end up having two idle cpu cores wasting time waiting for IO, even though just a drop of IO more to the second process would utilize the full power of its processing units. That how it used to be able to happen, I've heard it's been addressed around 2.6.32. Didn't have the opportunity to check that.
          There is only limited use in being able to vastly overload the cpu and still have a responsive system. Those scenarios does not happen that often but when they do, they are very annoying (and are not that uncommon in low-power systems). Now, with respect to IO (HDD), that's a different story - hdd's get overcommited all the time (less so with SSDs). It will be interesting to see that grouped.
          Also, if you read the lkml thread, there seems to be a will to generalize this (possibly trough userspace), to be able to assign scheduling groups by name to programs at will, not necessarily bound to a tty.
          This way you (the distros) could set certain programs to share a group and compete for cpu only within that group - no mater how they get started (one such group could be the build tools, another - image processing, or the desktop environment).
          The tty binding is just a quick and simple, yet powerful solution that allows to test this feature.
          I see quite some potential in this. Maybe linux will become the first 'always responsive' modern UI system. It makes image processing on a netbook possible. Will still take awfully long time, but you'll be able to forget about it while browsing or watching videos.
          Also, since it improves the determinism of scheduling, it should help in some real-time-ish problems and on embedded systems.

          Comment


          • Originally posted by popper View Post
            "This explains that you have absolutely no clue what "load" means It's not an absolute quantity like RAM or hard disk space"

            actually it IS an absolute quantity, no matter what OS etc you advocate, right down at the core,you have a fixed amount of micro ticks in which to perform a given task, you can not perform more than this total load in a given time slice.

            this is exactly where your scheduling for load comes in to it, you divide these limited ticks of time to move different parts of the sequentially run code to give the appearance of multitasking and responsiveness nothing more, so it is a absolute quantity.
            Bingo! And that's why E17 (for example) runs so much faster than for example Gnome, simply because it uses the bare needed amount of instructions.

            But in this day and age with 6 core i7 CPU's; it's also a matter of what's being done first and what is being done most. The scheduling is about what amount of instructions per time and what's first in line in time also contribute to the responsiveness ('x'-)factor.

            Comment


            • Originally posted by misiu_mp View Post
              I see quite some potential in this. Maybe linux will become the first 'always responsive' modern UI system. It makes image processing on a netbook possible. Will still take awfully long time, but you'll be able to forget about it while browsing or watching videos.
              I've seen this in Windows Vista and increasingly in Windows 7. People say that Windows 7 is so much faster, while in fact it's as slow as Vista, but it's UI is faster. In some situations the apps are even slower in Windows 7 while the UI is still 'silky-smooth'.

              I want this for Linux too, badly!

              Comment


              • I haven't seen any music/video skips on high cpu or IO load, when the load's ionice -c3 nice -n19. (idle IO prio + lowest CPU prio).

                Comment


                • Originally posted by curaga View Post
                  I haven't seen any music/video skips on high cpu or IO load, when the load's ionice -c3 nice -n19. (idle IO prio + lowest CPU prio).
                  Naturally - the load can be controlled with classical priorities as it always could. It is rather tedious to always remember to set them though.
                  This patch solves the problem automatically. Also when having more groups of applications running at the same time, it would be very difficult to adjust the priorities the classical way. Grouping will allow for a different way of dealing with this.

                  Comment


                  • Originally posted by V!NCENT View Post
                    I've seen this in Windows Vista and increasingly in Windows 7. People say that Windows 7 is so much faster, while in fact it's as slow as Vista, but it's UI is faster. In some situations the apps are even slower in Windows 7 while the UI is still 'silky-smooth'.
                    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?

                    Comment


                    • Let me know when it hits kernel mainline ppa.

                      Comment


                      • Originally posted by Beiruty View Post
                        Let me know when it hits kernel mainline ppa.
                        Of course. I will personally make sure You are immediately informed... That is because I as many others here have completely devoted my servitude towards your mainline ppa needs.

                        Comment


                        • Originally posted by misiu_mp View Post
                          Of course. I will personally make sure You are immediately informed... That is because I as many others here have completely devoted my servitude towards your mainline ppa needs.
                          I too am at your service allways. It is clear to me this patch is something you really need.

                          Comment


                          • Originally posted by misiu_mp View Post
                            Of course. I will personally make sure You are immediately informed... That is because I as many others here have completely devoted my servitude towards your mainline ppa needs.
                            Thanks, very much appreciated

                            Comment


                            • I hope systemd will come up with a real solution for this .... otherwise this would be the job of GUI developers.
                              But temporarily this patch will be nice sine I compile many things and sometimes its slows video-playback to much.

                              Comment


                              • Originally posted by Ragas View Post
                                I hope systemd will come up with a real solution for this .... otherwise this would be the job of GUI developers.
                                But temporarily this patch will be nice sine I compile many things and sometimes its slows video-playback to much.
                                Personally I don't think systemd is the right place to do it. Firstly systemd is NOT used by every distribution - hell right now none is even using it yet. It will take lots of time before it's mature enough to replace current solutions. Kernel on the other hand is used by every distribution. Secondly I believe it should be done in kernel level anyway.
                                Rob
                                email: dagger@gentoo.org

                                Comment

                                Working...
                                X