A better option would be for gnome-session, or some similarish program, to keep a global watch on memory and swap. When an application gets to a point that it is doing nothing but swapping, gnome-session could notice, nice it to maximum possible, or send SIGSTOP. That would freeze the program until gnome-session’s UI could handle it. Yes, it would swap, but there would still be swap available for gnome-session’s UI to work. That UI could identify the running application and ask you what you want to do.

]]> http://blogs.gnome.org/rbultje/2007/04/10/oom-killer-feature-in-os-x/comment-page-1/#comment-138 Jonathan Pryor Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/rbultje/2007/04/10/oom-killer-feature-in-os-x/#comment-138 The problem isn't the use (or lack thereof) of g_try_malloc(). The problem is Linux, which won't return an error from sbrk(2) and related APIs until all of physical RAM + swap has been completely exhausted (by default).<p/>So even if you used g_try_malloc(), you'd see the identical behavior as your entire system slid into swap and became nigh unusable.<p/>In theory, setting /proc/sys/vm/swappiness should control Linux's ability to use swap (i.e. you could force everything to be in RAM), in which case g_try_malloc() should return NULL, but I haven't heard of anyone actually trying this. The problem isn’t the use (or lack thereof) of g_try_malloc(). The problem is Linux, which won’t return an error from sbrk(2) and related APIs until all of physical RAM + swap has been completely exhausted (by default).

So even if you used g_try_malloc(), you’d see the identical behavior as your entire system slid into swap and became nigh unusable.

In theory, setting /proc/sys/vm/swappiness should control Linux’s ability to use swap (i.e. you could force everything to be in RAM), in which case g_try_malloc() should return NULL, but I haven’t heard of anyone actually trying this.

it can be very useful when a shiny new version of an application does not like the old settings.

1) The application requiring a large amount of memory and doing something similar to g_try_malloc and handling this failing gracefully. This is up to the application authors, but I bet they only check it when they’re allocating large amounts of memory like you required for your operation, and it wouldn’t have been so graceful if it was a few K of memory that it couldn’t obtain. (*)

2) The OS having Low memory handling as well as out of memory handling. Low memory situations would be triggered before being completely out of memory and an application starting to deal with it. I imagine if you’d continued you’d have hit the OOM handler and things would have been killed.

FWIW the N770/800 handles low memory and software can listen for the D-Bus signal and act accordingly by disabling some features that would be memory intensive. So it is possible on linux, I guess we just need some sort of desktop integration.

(*) Actually, I’ve just put it in my Marlin TODO, to use g_try_malloc to allocate the temporary buffers that it uses for things as these can be up to 2 meg each.

All it would take is a program (with a dialog already loaded so when memory is low it doesn’t get screwed out of space and cause the freeze), which monitors the memory use and the change in memory use and estimates the time until total consumption. When a certain small amount of memory is left, the application pauses processes that have been consuming memory or have very large memory consumption, blacklisting or whitelisting to prevent locking Xorg or something. (In gsm this is “Stop process”.) The dialog pops up telling you that you’re low on memory, these programs a suspect, and that you could kill them or pray the terminate nicely. Do what the user requests, and then resume the processes.

It doesn’t seem like it would be too terribly challenging but I would love to see this daemon.