Comment by Thaxll

7 years ago

At least windows doesn't freeze your whole desktop under heavy IO.

Edit: I'm getting downvoted by people that never used Linux probably.

39 comments

Thaxll

Reply
newnewpdro  7 years ago

You're being downvoted, but it's true about linux for at least two reasons to this day:

1. dm-crypt threads are unfair to the rest of the system's processes [1]. On dmcrypt systems, regular user processes can effectively raise their process scheduling priority in a multithreaded fashion by generating heavy IO on dmcrypt storage.

2. Under memory pressure, the VM system in linux will enter a thrashing state even when there is no swap configured at all. I don't have a reference on hand, but it's been discussed on lkml multiple times without solution. I suspect the recent PSI changes are intended as a step towards a solution though. What happens is clean, file-backed pages for things like shared libraries and executable programs become a thrashing set resembling anonymous memory swapping under memory pressure. As various processes get scheduled, they access pages which were recently discarded from the page cache as evictable due to their clean file-backed status when other processes ran under pressure, and now must be read back in from the backing store. This ping-ponging continues dragging everything down until either an OOM occurs or pressure is otherwise relieved. This often manifests as a pausing/freezing desktop with the disk activity light blazing, and it's only made worse by the aforementioned dmcrypt problem if these files reside on such volumes.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=199857

  • rikkus  7 years ago

    This behaviour - and perhaps other causes with similar issues for desktop users, is what drove me away from helping to make Linux ‘ready for the desktop’. The kernel philosophy was incompatible with the needs of desktop users. Those developing for the desktop (like myself) didn’t have the required expertise to make the kernel do the Right a Thing, and couldn’t find enough people willing or able to help.

    Things may have changed over the years - I’ve been running a Linux desktop recently and haven’t seen this kind of issue yet (the kind where you need to use magic keys to ask the kernel to kill all, sync and reboot) but reading your post, perhaps this is because RAM is much more plentiful these days.

    • zanny  7 years ago

      Its probably the ram plentiful thing. I haven't looked recently into if the Arch mainline kernel kconfig is just bad or not but the oomkiller is trash for me. Used to have the "recommended" swap == ram size but then the memory manager never even tried to cull pages until it was OOM and froze up trying to swap constantly. Currently running a 16/4 spread and probably going to drop to 16/1 because any time I hit memory limits everything just freezes permanently rather than the oomkiller getting invoked. I've hit it twice this week trying to render in Kdenlive and run a debug build of Krita...

  • blattimwind  7 years ago

    Yeah, I still observe this from time to time, with SSD-only storage and 32 GB main memory.

    • newnewpdro  7 years ago

      If more people reproduced the dmcrypt issue and commented in the bugzilla issue it'd put more pressure on upstream to revert the known offending commit.

      For some reason they seem to be prioritizing the supposedly improved dmcrypt performance over fairness under load, even though it makes our modern machines behave like computers from the 90s; unable to play MP3s and access the disk without audio underruns.

      I assume it's because they're not hearing enough complaints.

Zardoz84  7 years ago

I work and play every day over Linux and I never saw the desktop freezing.

  • kiwijamo  7 years ago

    I’ve attempted to use Linux and desktop freezing is the norm even on machines that run fine under windows. Admittedly the machines might be underpowered but that does call into question the commonly held belief that desktop Linux is better for low spec machines.

  • bnolsen  7 years ago

    I have had issues at times in the past but with things like core dumps on systems with spinning disk and 128gb ram. The OOM on linux can be brutally frustrating. But it's still light years ahead of windows for development...

zlynx  7 years ago

I haven't noticed Linux doing that in the last few years.

But honestly, that could also be the NVMe drives.

realusername  7 years ago

> At least windows doesn't freeze your whole desktop under heavy IO.

It does it as well on Windows and unlike Linux, Windows still has a risk of permanent damage under low space available, it was even worse in the XP days but these issues are still there.

black-tea  7 years ago

You're probably getting downvoted by people who have used Linux in the past 10 years.

  • Dayshine  7 years ago

    I'm on Linux right now and can cause this to happen by using more than 60% of my RAM. Afaik no distros correctly handle swapping onto a HDD.

    If I hit 80%, I get 10-20 second lock ups.

    If I hit >95%, I get 1-2 minute lock ups.

    Using Ubuntu 18.04.

    • opencl  7 years ago

      What is the "correct" handling of swap on an HDD supposed to be like? It is going to be slow no matter what you do. Windows also locks up for long periods of time if you use up almost all the RAM and it has to swap to HDD.

      8 replies →

    • el_isma  7 years ago

      Install earlyoom, it will kill processes before a lock up occurs. Greatly helped me (at the expense of random chrome tabs killed)

  • dralley  7 years ago

    I've experienced a total freeze before once one of my programs started swapping/thrashing. The entire desktop froze, not just the one program. This was in the past two years or so, so it's not a solved problem.

bnolsen  7 years ago

my experience with windows is that it freezes the whole desktop under moderately multithreaded loads.

eMSF  7 years ago

It doesn't? Oh right, you're bullshitting me.

Case in point: I recently tried unzipping the Boost library on an up-to-date Windows 10, and after trying to move the frozen progress window after a minute, the whole desktop promptly crashed. I have to say, the experience is better than it used to be, because at least the taskbar reappeared on its own. (Decompression succeeded on the second attempt after leaving the whole computer well alone ... but it certainly took its time even on a high-end desktop computer.)