Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 43

Thread: The Linux Desktop Responsiveness Patches Are Feeling Good

  1. #11
    Join Date
    Oct 2007
    Posts
    5

    Default

    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;
    }

  2. #12
    Join Date
    Jun 2010
    Posts
    34

    Default

    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 (:

  3. #13
    Join Date
    Mar 2010
    Posts
    30

    Default

    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)

  4. #14
    Join Date
    Oct 2006
    Posts
    534

    Default

    Quote 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
    DEV-NG: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    DEV: Intel S5520SC, 2xX5680, 36GB, 5x320GB, GTX550, F20/x86_64, Dell U2711 (^).
    SRV: Tyan Tempest i5400XT, 2xE5335, 8GB, 4x2TB, 9800GTX, F20/x86-64, Dell U2412.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  5. #15
    Join Date
    Oct 2006
    Posts
    534

    Default

    Quote 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
    DEV-NG: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    DEV: Intel S5520SC, 2xX5680, 36GB, 5x320GB, GTX550, F20/x86_64, Dell U2711 (^).
    SRV: Tyan Tempest i5400XT, 2xE5335, 8GB, 4x2TB, 9800GTX, F20/x86-64, Dell U2412.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  6. #16
    Join Date
    Oct 2007
    Posts
    5

    Default

    Quote 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.

  7. #17
    Join Date
    Oct 2007
    Posts
    5

    Default

    Quote 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.

  8. #18
    Join Date
    Oct 2006
    Posts
    534

    Default

    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-NG: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    DEV: Intel S5520SC, 2xX5680, 36GB, 5x320GB, GTX550, F20/x86_64, Dell U2711 (^).
    SRV: Tyan Tempest i5400XT, 2xE5335, 8GB, 4x2TB, 9800GTX, F20/x86-64, Dell U2412.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  9. #19
    Join Date
    Oct 2006
    Posts
    534

    Default

    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-NG: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    DEV: Intel S5520SC, 2xX5680, 36GB, 5x320GB, GTX550, F20/x86_64, Dell U2711 (^).
    SRV: Tyan Tempest i5400XT, 2xE5335, 8GB, 4x2TB, 9800GTX, F20/x86-64, Dell U2412.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  10. #20
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,766

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •