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

Jaya Kumar jayakumar.lkml at gmail.com
Fri Mar 17 14:58:56 UTC 2006


On 3/17/06, Alan Cox <alan at redhat.com> wrote:
> People have spent something like ten years trying heuristics for the OOM
> killer on Linux and not found a sane general case that always shoots the
> right thing. OLPC is a more controlled environment so who knows maybe it can
> be done
>

I hope I can offer a behavioral observation. I currently use a
wallmount touchscreen ( Geode GX2/CS5535/256MB CF/128 MB DDR-SDRAM (no
swap)) and I run firefox on top of Xorg on it. It is also used for
videoconferencing and in cases where our video conferencing app runs
overnight (it currently leaks memory slowly), the 2.6.14 OOM killer
seems to be smart enough to detect that and kill the videoconferencing
app rather than Xorg.

I had looked a little bit at OOM situations and noted:
- key processes on the system (Xorg, etc) can be protected from the
OOM killer by using /proc/self/oom_adj and setting it to -17
(OOM_DISABLE)
- oom killer selects the pid to murder by picking the pid that has the
highest mem size ( mm->total_mm + (all of it's children's mem size/2))
- long running + if_niced. this sounds nice and intuitive to me.
- the core oom killer function is badness() here
http://sosdg.org/~coywolf/lxr/source/mm/oom_kill.c#L46

IMHO, I think a background app that you may already be using to
display running battery stats etc, would be a good candidate to
leisurely watch free block count and if it dropped below a low
watermark, it would warn the user but take no preemptive action on
it's own. I think someone may already have suggested something similar
in this thread and I think this sounds the most intuitive to me.

Have a good weekend.

Best regards,
jaya




More information about the olpc-software mailing list