Announcement

Collapse
No announcement yet.

Kolivas Pushes New Kernel Responsiveness Patches

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

  • Kolivas Pushes New Kernel Responsiveness Patches

    Phoronix: Kolivas Pushes New Kernel Responsiveness Patches

    Con Kolivas had stopped working on the Linux kernel for two years after he became fed up with the kernel development community, but last year he made a return by introducing the BFS scheduler. The BFS scheduler for the Linux kernel is quite simple in design compared to other schedulers, but it performed fairly well on desktop systems...

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

  • #2
    It does not seem to be that new as there are dirs for .32 too:

    http://www.kernel.org/pub/linux/kern...k/patches/2.6/

    Comment


    • #3
      I seriously question the value of what is produced by this guy. Seems to me that more often than not, his work is unusably buggy and makes things explode in MS like frequency. There may be fringe cases that could benefit from a *decent* implementation of some of his ideas, but it is definitely not of benefit for general users. Especially not in the forms he produces them.

      Comment


      • #4
        I am particularly suspicious of the 10000Hz patch. A higher tick rate means more overhead. On the other hand, the overhead may still be tolerable on a fast system.

        Really, the thing that annoys me the most is system unresponsiveness in the face of high I/O. I can understand that reading a file can take a while if there is a lot of other disk I/O going on, but switching tabs on my browser should not be affected.

        Comment


        • #5
          Originally posted by droidhacker View Post
          I seriously question the value of what is produced by this guy. Seems to me that more often than not, his work is unusably buggy and makes things explode in MS like frequency. There may be fringe cases that could benefit from a *decent* implementation of some of his ideas, but it is definitely not of benefit for general users. Especially not in the forms he produces them.
          i personally consider CK one of few people hacking the kernel that actually understand what "desktop linux" should be about. that's what i respect about him.

          i remember the argument about BFS performance back on lkml, which clearly showed that linux developers have little idea of things average users do on their desktops.

          don't get me wrong - as much as i value CK, i still don't like his attitude :]

          now that he started making kernel patchsets again, his fanboys are probably flocking back (remember them from cfs vs SD flamewars?)

          Comment


          • #6
            It's good that he is working on his own implementations of schedulers and so on, so we can overtake them (if they are better) or use them to see bottlenecks in other implementation. It's a good thing that he helps, I can't see a problem with it.

            Comment


            • #7
              Originally posted by yoshi314 View Post
              i personally consider CK one of few people hacking the kernel that actually understand what "desktop linux" should be about. that's what i respect about him.
              Agreed. While I am not able to judge his code, I have experienced much better system responsiveness under heavy disk I/O with BFS than with any other scheduler in recent kernels. I also think that the argument that BFS's benefits do not scale well with high number of processors is totally moot since most of us will likely be sitting on machines with eight cores or less for years to come. BFS seems to have gotten more appreciation among the Android hacking crowd than among "traditional" linux hackers and is often available as an option for various ROMs published over at xda-developers.

              Comment


              • #8
                I'm using BFS almost since it came out. Without it, Linux here is much worse than Windows in GUI responsiveness. With BFS it's almost on-par.

                Comment


                • #9
                  Originally posted by waucka View Post
                  Really, the thing that annoys me the most is system unresponsiveness in the face of high I/O. I can understand that reading a file can take a while if there is a lot of other disk I/O going on, but switching tabs on my browser should not be affected.
                  I asked myself the same question.
                  From my "investigation" the fault lies also with Firefox. When you "just" switch tabs actually Firefox also reads/writes some files and that's where the unresponsiveness comes from (my hdd has very poor iops).

                  Comment


                  • #10
                    Originally posted by karl View Post
                    I asked myself the same question.
                    From my "investigation" the fault lies also with Firefox. When you "just" switch tabs actually Firefox also reads/writes some files and that's where the unresponsiveness comes from (my hdd has very poor iops).
                    Who's talking about Firefox? The problem is more general. 2.6.32 introduced changes in its scheduler (actually inspired by BFS) to make things better. But still, BFS gives better results.

                    Comment


                    • #11
                      Originally posted by waucka View Post
                      I am particularly suspicious of the 10000Hz patch. A higher tick rate means more overhead. On the other hand, the overhead may still be tolerable on a fast system.
                      I think you should read the notes in the patches first

                      The 10000Hz patch is not recommended:

                      "There's some really badly broken software out there that is entirely dependant on HZ for its maximum performance. Raise the maximum HZ value to some higher and slightly unreasonable values up to some higher and completely obscene values.
                      ...
                      Being over 1000, driver breakage is likely."

                      In other words, don't use it, unless you know what you are doing.

                      Comment


                      • #12
                        Originally posted by RealNC View Post
                        Who's talking about Firefox? The problem is more general. 2.6.32 introduced changes in its scheduler (actually inspired by BFS) to make things better. But still, BFS gives better results.
                        Maybe for you, because I don't notice any problems not related to slow 2D. I also notice my Linux system is more responsive then Windows - in example on my older hardware sound was stuttering in Windows under load. Last time I tried BFS it was in rather terrible state - dying input, very low performance in games when listening to the music same time (however, according to change log this problem is solved in the newest version). It seems BFS fits better on some configurations, but there are/were big problems with it.

                        Comment


                        • #13
                          Originally posted by yoshi314 View Post
                          i remember the argument about BFS performance back on lkml, which clearly showed that linux developers have little idea of things average users do on their desktops.
                          I remember that too. I believe Ingo posted something about BFS not working well on his 64 core system (or something with way too many CPUs). CK got pretty pissed about that understandably.

                          Comment


                          • #14
                            Originally posted by waucka View Post
                            I am particularly suspicious of the 10000Hz patch. A higher tick rate means more overhead. On the other hand, the overhead may still be tolerable on a fast system.

                            Really, the thing that annoys me the most is system unresponsiveness in the face of high I/O. I can understand that reading a file can take a while if there is a lot of other disk I/O going on, but switching tabs on my browser should not be affected.
                            using 100kHz tick in a practical system is highly not recomended.
                            This patch just provides more options with a max of 100kHz.
                            Some old genetics patch in the love sources 5years back did a similar thing and the system becomes all but unusable above 10kHz (kernel spending more time switching context then letting processes do stuff...)

                            I know I tried

                            Comment


                            • #15
                              Originally posted by waucka View Post
                              Really, the thing that annoys me the most is system unresponsiveness in the face of high I/O. I can understand that reading a file can take a while if there is a lot of other disk I/O going on, but switching tabs on my browser should not be affected.
                              You should try the latest kernel. I can't remember which kernel has it (2.6.32 or 2.6.33) but there's a change in there that should significantly improve IO read latencies under heavy write loads.

                              Comment

                              Working...
                              X