Announcement

Collapse
No announcement yet.

The Linux Desktop Responsiveness Patches Are Feeling Good

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

  • #16
    Originally posted by gilboa View Post
    No sure what you are trying to prove, nor do I understand what this has to do with the subject at hand...
    This test will bring ANY (Unix/Linux) OS - as long as the admin is stupid enough to setup a multi-user system without using limits.conf to limit the per user resource consumption. (Win2K3/8 suffer from the same problem, and use a comparable solution - though MS' solution makes limits.conf look user-friendly)
    The problem I've seen, is that this not only brings down the offending process to a crawl (which it should) but that the rest of the system becomes REALLY unresponsive, even processes not touching disk I/O. And processes touching disk doesn't get their fair share, I.E. with one memhog and one I/O-bound process on same nice and ionice, the I/O-bound seems to be getting far less than it's fair half performance. Haven't tested this last bit for a few kernels though, that particular part may have been fixed.

    Setting ulimit (-m) low, the first thing I tried, seems to not solve the problem, on some machines (my old nForce-based motherboard is one of them) it even increases the problem due to forcing swapping much earlier.

    I have not been able to fully eliminate these hard drops in repsonsivenes by any means, short of running 32-bit PAE on a machine with much ram, in which case at least single offending processes will get OOM before they trigger swapping, or of course disable the swap which also has it's downsides.

    In a multi-user-system, for intentional DoS, personally I do not know a reasonable way to combat it. (Short of disabling swap) For me, ulimit -m doesn't help much, -v hurts even non-problematic cases like mmap. Perhaps there are ways to limit per-user use via cgroups or other quota mechanisms though?

    That is why I was interested to see if the behavior is better with these new patches. When investigating, I've got a shoddy feeling that the process scheduler blocks on I/O instead of deferring execution of the swapped out-process, in favor of processes that could actually run now.

    Comment


    • #17
      Originally posted by gilboa View Post
      No sure what you are trying to prove, nor do I understand what this has to do with the subject at hand...
      This test will bring ANY (Unix/Linux) OS - as long as the admin is stupid enough to setup a multi-user system without using limits.conf to limit the per user resource consumption. (Win2K3/8 suffer from the same problem, and use a comparable solution - though MS' solution makes limits.conf look user-friendly)
      Oh, one more thing. Tested this on OSX about 6 months ago. The behavior were quite a bit more sane there. Definitely noticable slowdown, as would be expected, but there was no problem at all regaining control and manually killing the process.

      On the Linux systems I've tried this, ssh usually fails to login before timeout, X becomes so slow it takes minutes to switch window, and just getting feedback on typing in a raw TTY makes you give up and hit Alt+SysRq+F, or just hit the hard-reset button. Although, there seems to be slight variations with hardware. Some systems go down completely, while some fairs slightly better. On my old IBM T43 for instance, you could actually kill the process without killing the machine, with a lot of patience (~3-4 minutes to regain control, if you had shifted window). On my Asus P6T SE-based machine, you may as well give up.

      Comment


      • #18
        While this patch may or may not mitigate the problem (read: improve the performance hit once the kernel goes swap happy) it will not solve the underlying problem, read: Using swap as a DOS vector.
        It doesn't matter if your machine needs 20 seconds to open a VT or 2 minutes, unless you plug the hole (read: letting a user hog all the memory), the DOS vector remains. You simply have better luck in stopping it before the system dies. (Plus, the user can simply add forks to the code listed below, eating CPU as well, making any attempt to login more-or-less impossible with or without this patch)

        Yes, ulimit -v (I'm not sure that rss is honored anymore; I still use it just-in-case) does interfere with mmap (AFAIR only wine goes space happy when I lower mmap below 2.78GB), but as it stands, it the only possible solution on low-memory machines to plug this DOS vector.

        Granted, using a 64bit machine with >4GB RAM works far better (You can setup ulimit -v to 3GB without killing wine) but 64bit-machine-with-memory-to-spare are far less inclined to go into dead-io-wait mode to begin with.

        P.S. you could achieve the same result by using this code.
        Code:
        $ echo "int main(int argc, char *argv[]) { while ( 1 ) { void *v = malloc(4096); memset(v,0,4096); }; return 0; };" | gcc -xc -o kill_machine - && ./kill_machine
        DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
        SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
        BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
        LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

        Comment


        • #19
          P.S.
          I'm not saying the Linux doesn't have a problem with responsiveness when swapper goes swap happy. Quite the contrary.
          I -am- saying that the responsiveness of the system during such an event has nothing to do with having swap-bomb being used as a DOS vector. (due to the reasons listed above).

          The only viable solution, especially on resource limited machines with multiple users, is ulimit enforcement. wine (and other mmap happy applications) be damned.

          - Gilboa
          DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
          SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
          BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
          LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

          Comment


          • #20
            Originally posted by gilboa View Post
            P.S.
            I'm not saying the Linux doesn't have a problem with responsiveness when swapper goes swap happy. Quite the contrary.
            I -am- saying that the responsiveness of the system during such an event has nothing to do with having swap-bomb being used as a DOS vector. (due to the reasons listed above).

            The only viable solution, especially on resource limited machines with multiple users, is ulimit enforcement. wine (and other mmap happy applications) be damned.

            - Gilboa
            This is off-topic to the problem at hand. This thread is about the desktop freezing when copying a 500MB file while I have 5GB free RAM.

            Comment


            • #21
              Originally posted by DeepDayze View Post
              Damentz (he's one of the zen devs) has some experience with backporting patches so he might take a crack at backporting all 7 patches to 2.6.35 (and maybe 2.6.34)
              I backported them two days ago -> http://git.zen-kernel.org/?p=kernel/...eads/mm-2.6.34

              You'll want to merge this branch into your 2.6.34 kernel tree.

              Comment


              • #22
                Originally posted by damentz View Post
                I backported them two days ago -> http://git.zen-kernel.org/?p=kernel/...eads/mm-2.6.34

                You'll want to merge this branch into your 2.6.34 kernel tree.
                Great!

                You put them all into your latest 2.6.35 kernel right?

                Comment


                • #23
                  Originally posted by DeepDayze View Post
                  Great!

                  You put them all into your latest 2.6.35 kernel right?
                  Yes, 2.6.35 already had the necessary bits, no extra backporting is required.

                  Comment


                  • #24
                    Where are the patches for 2.6.35?

                    Comment


                    • #25
                      Originally posted by gilboa View Post
                      Are you for real?
                      You don't protect your machine by setting the right limits and you expect, what? That the kernel will magically transform your ultra-slow HD into a RAM like speed-daemon? Maybe it should kill your process with an EIDIOTPROTECTION error? Come-on!

                      - Gilboa
                      I meant that swapping always makes the problem with responsiveness to come up. If you open a file larger than the RAM /~10 GB *.txt/ with let's say UltraEdit /found it in the Ubuntu Software Center/ the OS will not crawl, because there will be no excessive swapping. Actually I had more than 2 gb spare to start a virtualbox and try the changes to the file.
                      Every intense use of the hard disks makes it visible. I have three drives and I always try to balance the load when large amounts of data have to be transferred or extracted or etc. and even then it's perceivable.
                      Greetings.

                      Comment


                      • #26
                        Originally posted by rewind View Post
                        I meant that swapping always makes the problem with responsiveness to come up. If you open a file larger than the RAM /~10 GB *.txt/ with let's say UltraEdit /found it in the Ubuntu Software Center/ the OS will not crawl, because there will be no excessive swapping. Actually I had more than 2 gb spare to start a virtualbox and try the changes to the file.
                        Every intense use of the hard disks makes it visible. I have three drives and I always try to balance the load when large amounts of data have to be transferred or extracted or etc. and even then it's perceivable.
                        Greetings.
                        Obviously that the system will start swapping when you open something that takes up more than the physical RAM, but with these patches the swapping is supposed to be done in a way that does not excessively slow down the system such as swapping out things that are not actively in use.
                        For example if your web browser is active, the system won't try to swap it out

                        Comment


                        • #27
                          Originally posted by DeepDayze View Post
                          Obviously that the system will start swapping when you open something that takes up more than the physical RAM, but with these patches the swapping is supposed to be done in a way that does not excessively slow down the system such as swapping out things that are not actively in use.
                          For example if your web browser is active, the system won't try to swap it out
                          even if you don't use Con's BFS cpu scheduler, give his ck1 patchset on top of 2.6.35 a try !

                          combine them with this patch and you'll have a way more responsive system

                          if you want to improve on top of that: use BFQ (included in the zen-kernel) and BFS

                          Comment


                          • #28
                            BFQ makes the problem worse for me.

                            Comment


                            • #29
                              Originally posted by DeepDayze View Post
                              Obviously that the system will start swapping when you open something that takes up more than the physical RAM, but with these patches the swapping is supposed to be done in a way that does not excessively slow down the system such as swapping out things that are not actively in use.
                              For example if your web browser is active, the system won't try to swap it out
                              Which is just brilliant! I'll definitely gonna try them. Thanks for the explanation.

                              Comment


                              • #30
                                I'm still looking for the full set of those patches for 2.6.35. Where are they?

                                Comment

                                Working...
                                X