[olpc-software] graceful handling of out-of-memory conditions

Alan Cox alan at redhat.com
Tue Mar 28 14:13:06 UTC 2006


On Tue, Mar 28, 2006 at 08:59:20AM -0500, David Zeuthen wrote:
>  - All child processes inherit this; HAL, NM, the X server, the panel,
>    the WM etc.

You want to set these not to disable but to "last resort" - ie almost disable
otherwise you'll deadlock if one of them leaks.

>  - Our desktop shell sets /proc/pic/oom_adj to something != OOM_DISABLE
>    for child processes launched (e.g. Firefox, Abiword etc.) 

Yep. For firefox I suspect "shoot me first"

> What do you think?

I think its likely in the OOM enabled case that you will take 10 minutes
of unusuable box and frozen pointer before you get an OOM event, especially
if you are dealing in lots of small allocations and in the no overcommit case
it doesn't occur anyway. You can't mix the two otherwise one app can overcommit
another anyway.

Would it be useful if there were two levels of "no room" (actually there 
already are but its hardcoded for root). In other words the system rules would
be something like

	100% swap + 60% ram + oom_adj based value

so instead of hitting OOM we would refuse allocations which is what we need to
do to keep the box running sanely not bog down but we would refuse allocations
to applications before things like the WM and panel.





More information about the olpc-software mailing list