Announcement

Collapse
No announcement yet.

The Linux Desktop Responsiveness Patches Are Feeling Good

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

  • #11
    If someone has the patches running, it would be interesting to see how it fares with this little test; (adjust MEM_SIZE to match your physical ram)

    For a long time, this has managed to bring almost all my Linux-systems to a crawl, not surprising since it basically forces excessive swapping. My worry though, and the reason that I investigated it, is that occasionally some application is bound to go haywire and do something like this.

    On some systems, the result is so bad, I can't even regain control of the system in reasonable time. IMHO, this is a plausible denial-of-service attack for any multi-user-system, or any service which can be triggered to excessive ram consumption.

    /* Stupid program aiming to eat the swap alive */
    #include <stdlib.h>
    #include <string.h>

    size_t MEM_SIZE = 1024*1024*1024;
    float MEM_USE = 2;
    size_t ALLOC_SIZE = 4*1024*1024;

    int main() {
    char **lists;
    char *list;
    size_t i,j;
    size_t lists_len = (MEM_SIZE*MEM_USE) / ALLOC_SIZE;

    lists = malloc(lists_len * sizeof(list));
    for (i = 0; i < lists_len; i++)
    lists[i] = malloc(ALLOC_SIZE);

    while (1) {
    for (i = 0; i < lists_len; i++)
    memcpy(lists[i], lists[(i+1)%lists_len], ALLOC_SIZE);
    }
    return 0;
    }

    Comment


    • #12
      Try to open more than the RAM in size text file /2-4 GB/ with gedit and it'll be enough. Happened to me already (:

      Comment


      • #13
        I rolled my own 2.6.35 kernel with this and the bfq patches

        2.6.35-amd64-iowait-bfq #1 SMP PREEMPT

        And the general responsiveness of the system under IO load is night and day compared to how it was before, copying a 3.7gig file from one of my NTFS drives (i know, i know, leftover from my switch from windows) used to bring the system to a halt, programs used to freeze up until it had finished etc.

        Now, everything keeps going, and copying speed is just as good (I haven?t timed it to compare)

        (this is on a Debian squeeze/testing base btw)

        Comment


        • #14
          Originally posted by rawler View Post
          #include <stdlib.h>
          #include <string.h>

          size_t MEM_SIZE = 1024*1024*1024;
          float MEM_USE = 2;
          size_t ALLOC_SIZE = 4*1024*1024;

          int main() {
          char **lists;
          char *list;
          size_t i,j;
          size_t lists_len = (MEM_SIZE*MEM_USE) / ALLOC_SIZE;

          lists = malloc(lists_len * sizeof(list));
          for (i = 0; i < lists_len; i++)
          lists[i] = malloc(ALLOC_SIZE);

          while (1) {
          for (i = 0; i < lists_len; i++)
          memcpy(lists[i], lists[(i+1)%lists_len], ALLOC_SIZE);
          }
          return 0;
          }
          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)

          - Gilboa
          oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
          oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
          oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
          Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

          Comment


          • #15
            Originally posted by rewind View Post
            Try to open more than the RAM in size text file /2-4 GB/ with gedit and it'll be enough. Happened to me already (:
            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
            oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
            oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
            oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
            Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

            Comment


            • #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
                  oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                  oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                  oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                  Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                  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
                    oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                    oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                    oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                    Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                    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

                      Working...
                      X