7 ms·

At least windows doesn't freeze your whole desktop under heavy IO. Edit: I'm getting downvoted by people that never used Linux probably.

by Thaxll 8y ago

zlynx 8y ago
I haven't noticed Linux doing that in the last few years. But honestly, that could also be the NVMe drives.
eMSF 8y 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.)
- dang 8y ago
  Could you please leave personal swipes out of your comments here? They have a degrading effect on discussion and evoke worse from others. Your comment would be just fine without the second sentence. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Zardoz84 8y ago
I work and play every day over Linux and I never saw the desktop freezing.
- kiwijamo 8y 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 8y 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...
Valmar 8y ago
Depends entirely on your choice of I/O Scheduler. With bfq-mq, I've encountered no desktop freezing under heavy I/O.
- kiwijamo 8y ago
  Do any mainstream distro use this?
realusername 8y 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.
bnolsen 8y ago
my experience with windows is that it freezes the whole desktop under moderately multithreaded loads.
black-tea 8y ago
You're probably getting downvoted by people who have used Linux in the past 10 years.
- Dayshine 8y 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 8y 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.
    - Dayshine 8y ago
      When I say lock up I mean the UI completely stops. As in, my i3 bar stops updating for several minutes. Not even the linux magic commands let me recover. On windows things may be unresponsive, but at least ctrl-alt-del responds, and at least the mouse moves! The main difficulty is I can't tell if my machine has crashed vs is overloaded if the UI doesn't do anything for several minutes.
      - zozbot123 8y ago
        If you renice the UI processes to a higher-than-normal priority, it should work more like it does in Windows. (This used to be somewhat risky, but today Linux UI is not going to hog your system resources.) The underlying problem is that when memory is tight, Linux starts evicting "clean" pages from the page cache that actually will need to be accessed shortly afterwards (i.e. they're part of the working set of some running process), and thrashing occurs. There's no easy solution to this issue, other than making user programs more responsive to memory pressure in the first place. (This could extend as far as some sort of seamless checkpoint+resume support, like what you see in mobile OS's today.)
adontz 8y ago
It does? It does even much weirder things. https://blogs.technet.microsoft.com/markrussinovich/2007/08/26/vista-multimedia-playback-and-network-throughput/ https://blogs.technet.microsoft.com/markrussinovich/2007/08/...
- qha 8y ago
  Oh my God, they pretended everybody has a 100 Mbps NIC and capped at that speed. That's completely retarded. At least I'm going to give them credit for disclosing what the problem was. I would've be too ashamed to admit it.
newnewpdro 8y 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 https://bugzilla.kernel.org/show_bug.cgi?id=199857
- blattimwind 8y ago
  Yeah, I still observe this from time to time, with SSD-only storage and 32 GB main memory.
  - newnewpdro 8y 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.
- Dylan16807 8y ago
  Is there no way to set a minimum page cache size?

At least windows doesn't freeze your whole desktop under heavy IO. Edit: I'm getting downvoted by people that never used Linux probably.

by Thaxll 8y 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.

zlynx 8y ago

I haven't noticed Linux doing that in the last few years. But honestly, that could also be the NVMe drives.

eMSF 8y 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.)

dang 8y ago
Could you please leave personal swipes out of your comments here? They have a degrading effect on discussion and evoke worse from others. Your comment would be just fine without the second sentence. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Zardoz84 8y ago

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

kiwijamo 8y 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 8y 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...

Valmar 8y ago

Depends entirely on your choice of I/O Scheduler. With bfq-mq, I've encountered no desktop freezing under heavy I/O.

kiwijamo 8y ago
Do any mainstream distro use this?

realusername 8y 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.

bnolsen 8y ago

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

black-tea 8y ago

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

Dayshine 8y 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 8y 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.
  - Dayshine 8y ago
    When I say lock up I mean the UI completely stops. As in, my i3 bar stops updating for several minutes. Not even the linux magic commands let me recover. On windows things may be unresponsive, but at least ctrl-alt-del responds, and at least the mouse moves! The main difficulty is I can't tell if my machine has crashed vs is overloaded if the UI doesn't do anything for several minutes.
    - zozbot123 8y ago
      If you renice the UI processes to a higher-than-normal priority, it should work more like it does in Windows. (This used to be somewhat risky, but today Linux UI is not going to hog your system resources.) The underlying problem is that when memory is tight, Linux starts evicting "clean" pages from the page cache that actually will need to be accessed shortly afterwards (i.e. they're part of the working set of some running process), and thrashing occurs. There's no easy solution to this issue, other than making user programs more responsive to memory pressure in the first place. (This could extend as far as some sort of seamless checkpoint+resume support, like what you see in mobile OS's today.)

adontz 8y ago

It does? It does even much weirder things. https://blogs.technet.microsoft.com/markrussinovich/2007/08/26/vista-multimedia-playback-and-network-throughput/ https://blogs.technet.microsoft.com/markrussinovich/2007/08/...

qha 8y ago
Oh my God, they pretended everybody has a 100 Mbps NIC and capped at that speed. That's completely retarded. At least I'm going to give them credit for disclosing what the problem was. I would've be too ashamed to admit it.

newnewpdro 8y 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 https://bugzilla.kernel.org/show_bug.cgi?id=199857

blattimwind 8y ago
Yeah, I still observe this from time to time, with SSD-only storage and 32 GB main memory.
- newnewpdro 8y 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.
Dylan16807 8y ago
Is there no way to set a minimum page cache size?