Re: Emergency memory pool for Glib

[Havoc Pennington <hp redhat com>]

Federico Mena Quintero wrote:
> Hi,
>
> One important thing, especially for embedded devices, is to ensure that
> GTK+ apps won't abort() when g_malloc() fails.
>
> I've started a wiki page to discuss having an emergency memory pool:
>
> 	http://live.gnome.org/GTK%2B/LowMemoryPool
>
> [Robert O'Callahan says that Nokia has a patch to do something like
> this... can we simply use it?]
>
> Thoughts?

After random lunchtime chatter with Owen, I'd think you want:

 - g_malloc blocks on OOM by default
 - the system has a process which has all its memory 
preallocated/reserved; the purpose of this process is to show a "what 
should I kill?" kind of UI, or to just magically kill the right thing 
(though the kernel has struggled a lot with the "what to kill on OOM" 
question, it should be easier in userspace since we can know what's the 
X server, what's critical desktop processes, etc.)
 - (whether the preallocation is just careful coding in this "monitor
process" or a kernel thing sort of like the 5% disk reserved for 
superuser, I don't know)

Then if you run out of memory, most of the apps hang; the "oom user 
interaction" app does not and either figures out or asks the user what 
to do, then with memory pressure relieved the other apps can unblock and 
continue.

If you try to handle it app-by-app you'll get a dialog from every single 
app in a typical oom situation. Also the mem parachute would waste ram 
in every app, and if one app was leaking it wouldn't even do any good, 
or would only help briefly.

Havoc