4 ms·

Swap doesn't resolve this on a HDD though. The UI/terminal still locks up, and you still can't recover once you hit the point of thrashing. What really confuse

Swap doesn't resolve this on a HDD though. The UI/terminal still locks up, and you still can't recover once you hit the point of thrashing. What really confuses me is that this kernel was developed when SSDs didn't exist, so how on earth did "The system becomes irrecoverably unresponsive if a single application uses too much RAM" get missed?

wott 7y ago
> so how on earth did "The system becomes irrecoverably unresponsive if a single application uses too much RAM" get missed? I don't know, there are/were several similar issues (very basic situations, frequently encountered by everyone or at least many people) which are/were not fixed for years (we might say decade(s)): that one dealing with memory exhaustion; then right after that, the problem which follows when memory is freed but the system is still unresponsive for several minutes(!); freezing when writing to a USB disk; freezing when something goes wrong on a NFS mount... I never understood why those common and really important issues were not tackled (or not tackled before many, many years). IMO they were such basic functionalities, which a proper OS is expected to perform reliably as a basis for and before all the rest, it should have been dealt with and granted highest priority.
dredmorbius 7y ago
It didn't get missed. We kill -9d and rebooted a lot.
michaelmrose 7y ago
It didn't get missed its just that nobody cared enough. Servers can be provisioned with way more than enough memory for its use case and can have spares configured to take up the load if it has to be killed. On the desktop side the issue happens far less if you have more than enough memory. A developer running vim and firefox/chrome on his 32GB of ram machine is vastly less likely to experience this issue than a cheap laptop with 4GB of ram.

4 ms·

Swap doesn't resolve this on a HDD though. The UI/terminal still locks up, and you still can't recover once you hit the point of thrashing. What really confuse

by Dayshine 7y ago

wott 7y ago
> so how on earth did "The system becomes irrecoverably unresponsive if a single application uses too much RAM" get missed? I don't know, there are/were several similar issues (very basic situations, frequently encountered by everyone or at least many people) which are/were not fixed for years (we might say decade(s)): that one dealing with memory exhaustion; then right after that, the problem which follows when memory is freed but the system is still unresponsive for several minutes(!); freezing when writing to a USB disk; freezing when something goes wrong on a NFS mount... I never understood why those common and really important issues were not tackled (or not tackled before many, many years). IMO they were such basic functionalities, which a proper OS is expected to perform reliably as a basis for and before all the rest, it should have been dealt with and granted highest priority.
dredmorbius 7y ago
It didn't get missed. We kill -9d and rebooted a lot.
michaelmrose 7y ago
It didn't get missed its just that nobody cared enough. Servers can be provisioned with way more than enough memory for its use case and can have spares configured to take up the load if it has to be killed. On the desktop side the issue happens far less if you have more than enough memory. A developer running vim and firefox/chrome on his 32GB of ram machine is vastly less likely to experience this issue than a cheap laptop with 4GB of ram.