I'll soon be flying to Greece for GUADEC but wanted to mention one of the things I worked on the past couple of weeks: the low-memory-monitor project is off the ground, though not production-ready.
low-memory-monitor, as its name implies, monitors the amount of free physical memory on the system and will shoot off signals to interested user-space applications, usually session managers, or sandboxing helpers, when that memory runs low, making it possible for applications to shrink their memory footprints before it's too late either to recover a usable system, or avoid taking a performance hit.
It's similar to Android's lowmemorykiller daemon, Facebook's oomd, Endless' psi-monitor, amongst others
Finally a GLib helper and a Flatpak portal are planned to make it easier for applications to use, with an API similar to iOS' or Android's.
Combined with work in Fedora to use zswap and remove the use of disk-backed swap, this should make most workstation uses more responsive and enjoyable.
6 comments:
I think some applications, which could fast save one's state to disk, can save it's state and exit. Of course, in case of small free memory amount.
That's already what the GLib API advises in the API documentation.
Sound interesting.
So there are already couple of low memory deamons. How's your different?
> So there are already couple of low memory deamons. How's your different?
As mentioned in the text, it "will shoot off signals to interested user-space applications". It's targeted at "traditional" Linux desktops, like GNOME and everything else I work on.
Really looking forward to this. I often hit OOM when working with large files in Blender VSE, Inkscape, Scribus or GIMP. Most of the time when these things happen, they happen unpredictably. But if it's interesting, I can try to help with finding reproducible cases - I think partly some of them is OOM related, partly some of them is related to operations blocking the UI thread...
Post a Comment