Jonas

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)

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)

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)

@rmader@mastodon.social yup, I think all the things necessary are quite doable. Systemd could also dynamically create/remove swapfiles based on memory pressure (IIRC this was even discussed at some point). Probably the reason nobody does is that developers just don’t run into these issues, because they all get the beefiest machines with 64 gigs of ram :/

@1peter10@chaos.social Yup, you're talking about hibernation (aka writing memory to disk and then shutting down). Not exactly cutting edge technology, it even works on most linux devices if you set it up. Unsurprisingly, Linux distros don't care enough to make hibernate work OOTB, I'm hoping we can figure it out for GNOME OS though.

@tbernard@mastodon.social @pid_eins@mastodon.social All of the above, this kind of stuff needs work all across the stack.

@matzipan@hachyderm.io sure, but distros aren’t using it by default, nor do we have a good way to dynamically manage swap. And if memory actually runs out, we just go on a killing spree and kill apps, rather than freezing them and letting the user decide what to do.

@dpk@chaos.social @rmader@mastodon.social @fogti@chaos.social mmh interesting.. I guess this would be as far as you can get for the dynamic swap files if you want to avoid doing kernel work.

@x0@dragonscave.space Nope, but would be interesting to take a look. I think they are also notoriously bad at this, so wouldn’t expect too much…

@karolherbst@chaos.social systemd-swap is unmaintained though :/ It seems like in the kernel things are in motion when it comes to mm right now. zram just gained compressed writeback, and zram can also set a custom writeback device, so potentially that could be used as a "fake" swapfile.

@root42@chaos.social I don’t think anyone in userspace handles malloc() failures, might as well kill apps instead…

@matzipan@hachyderm.io They are actually downloading more ram, by just using more and more of the SSD as ram, all the way to the point where the SSD runs out of space. :)

@matzipan@hachyderm.io ah yeah, that one’s just a random screenshot where there’s not that much opened yet.