@root42 @verdre Swap thrashing went away forever for me when I started using these sysctl settings:
vm.overcommit_memory = 2
vm.overcommit_ratio = 95
vm.dirty_background_bytes = 16777216
vm.dirty_background_ratio = 0
vm.dirty_bytes = 67108864
vm.dirty_ratio = 0
which means no overcommit, reserve 5% of swap for root, start background writeback at 16 *megabytes* of dirty data and throttle writers at 64 megs
I'd love to work with someone on a proper study of whether this makes sense for everyone
@verdre you can disable memory overcommitment I think? Never tried that, as I rarely have issues with OOM. But it should give processes an error when they try to malloc, which they then could handle.
@root42 @verdre I have not tested this thoroughly, but I believe that a hefty chunk of Linux's problems with swap thrashing are, at root, caused by its default heuristic that allows 20% of RAM to fill up with data that needs to get written to disk, before it actually starts making write() wait for the disk.
20% of RAM nowadays can easily be in the gigabytes. It takes at least a few seconds to flush all of that to even the fastest SSDs. But it takes only milliseconds to fill it up.
@root42 @verdre Swap thrashing went away forever for me when I started using these sysctl settings:
vm.overcommit_memory = 2
vm.overcommit_ratio = 95
vm.dirty_background_bytes = 16777216
vm.dirty_background_ratio = 0
vm.dirty_bytes = 67108864
vm.dirty_ratio = 0
which means no overcommit, reserve 5% of swap for root, start background writeback at 16 *megabytes* of dirty data and throttle writers at 64 megs
I'd love to work with someone on a proper study of whether this makes sense for everyone
Once my 16 GB of memory were filled up, with a good extra amount saved thanks to compression, macOS just started creating swapfiles. Memory pressure went from the green to the yellow area, things got a little bit sluggish when switching to the oldest tabs, but no major slowdowns or freezes of multiple seconds.
The more tabs were open, the more swap files got created. At some point the disk would fill up though.
(2/4)
With about 200 MB of disk space left, Firefox froze completely, and at the same time a window popped up telling me that Firefox and a few other apps were frozen (not killed!!!) by the system.
The window prompted to either kill the app or resume it. Pressing resume, Firefox continued running smoothly for a few seconds, until it got frozen again. Pressing resume again, I could quickly close a few tabs, and things worked fine again.
(3/4)
All of this without one tab getting unloaded by Firefox, or one app getting killed without user consent.
So OOM conditions *can* be handled without losing people's data. Don't let kernel developers fool you into believing this is an impossible problem to solve.
(4/4)
@verdre I recently came to the same conclusion that the fundamental mistake in how out-of-memory situations are handled under #Linux is that it's based on killing processes rather than pausing them. That leads to doing nothing until it's too late, because killing a process can result in data loss whereas pausing it is relatively harmless (and entirely normal in #Android).
It isn't really a problem with the kernel though. It's the desktop environments that should handle pausing apps when OOM.
A space for Bonfire maintainers and contributors to communicate
Install bonfire.cafe
Get the full app experience
