Announcement

Collapse
No announcement yet.

Fixed: The Linux Desktop Responsiveness Problem?

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

  • #41
    People to check whether it solves the problem for you or not, try the test in


    If it solves for you don't forget to tell on the bug report what you've observed and that you would like it to be fixed in the stable kernels too.

    Keep in mind if you only have one non-ssd disk there will always be a UI slowdown and less responsiveness when doing heavy i/o. The goal of this patch is to reduce that slowdown, but I believe its almost impossible to have no slowdown at all.

    Remember to be polite, and if you are going to say "+1 me too!" please don't bother.

    Comment


    • #42
      People to check whether it solves the problem for you or not, try the test in


      If it solves for you don't forget to tell on the bug report what you've observed and that you would like it to be fixed in the stable kernels too.

      Keep in mind if you only have one non-ssd disk there will always be a UI slowdown and less responsiveness when doing heavy i/o. The goal of this patch is to reduce that slowdown, but I believe its almost impossible to have no slowdown at all.

      Remember to be polite, and if you are going to say "+1 me too!" please don't bother.

      Comment


      • #43
        sorry if this seems like a lazy and noobish request, but i'd be glad to test this out if somebody would make a .deb for any ubuntu kernel with the patch

        Comment


        • #44
          Originally posted by kernelOfTruth View Post
          Code:
          if (should_reclaim_stall(nr_taken, nr_freed, priority, sc)) {
          The original patch uses nr_reclaimed in place of nr_freed, even though the parameter is then named nr_freed in the definition. Not too sure about that one, in doubt I'd go with the original path, so nr_reclaimed, not nr_freed.

          Comment


          • #45
            Originally posted by KhaaL View Post
            sorry if this seems like a lazy and noobish request, but i'd be glad to test this out if somebody would make a .deb for any ubuntu kernel with the patch
            Cross your fingers,.

            sudo apt-get build-dep linux-source
            sudo apt-get install linux-source make-kpkg
            cd /usr/src
            sudo tar vxf linux-source-2.6.32.tar.bz2
            ln -s linux-source-2.6.32 linux
            cd linux
            cp /boot/config-2.6.32-21-generic ./.config


            Not sure where to get the patches in a file so you can just wget but


            next just...

            sudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers

            you'll find your deb's in the /usr/src





            or just

            Comment


            • #46
              wherever you find the patch files just
              patch -p0 < whereverthepatchwas.txt

              Comment


              • #47
                This may sound stupid, but if the I/O gets in the way with the execution of the rest of the kernel then can't the specific I/O be in another thread?

                Comment


                • #48
                  Originally posted by V!NCENT View Post
                  This may sound stupid, but if the I/O gets in the way with the execution of the rest of the kernel then can't the specific I/O be in another thread?
                  Reading through the messages posted, it looks like that was exactly one of the problems that got fixed - it was already in another thread, but other threads were needlessly blocking on it whenever they hit a page fault.

                  disclaimer - i only half understood most of what was going on, so the above is nothing more than an educated guess and could be wrong.

                  p.s. - i think the logic of blocking at all has to do with performance and running out of memory. if you're low on memory it makes sense to page blocks of memory out to disk at a time rather than constantly doing 4K over and over again, and i think there was just a bug in the way it was implemented.

                  Comment


                  • #49
                    for those still having problem with this merged 2-part patch use the one from the zen-kernel devs:

                    git.zen-kernel.org diff

                    Comment


                    • #50
                      Originally posted by smitty3268 View Post
                      p.s. - i think the logic of blocking at all has to do with performance and running out of memory.
                      In other words: When you're writing a shitload of bytes to the storage device and you use that same storage device for swapping everything slows down.

                      Seems pretty obvious, actually

                      Also sounds like: You use too more mem then you have, so enlarge your RAM capacity
                      PS: should be cheaper than a new HDD once it fails due to constant writes...

                      Comment

                      Working...
                      X