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

Alan Cox alan at redhat.com
Tue Mar 28 15:44:08 UTC 2006


On Tue, Mar 28, 2006 at 10:03:09AM -0500, David Zeuthen wrote:
> > otherwise you'll deadlock if one of them leaks.
> 
> Well, if one of them leaks we would have identified this in testing yes?

Bwhahaha. Most unlikely judging by the state of software today. Yes testing
or more likely first users will find the big ones but not the obscure ones.

> I really think we don't want to kill them; we want a rock solid base of
> services we can always assume are there; sure if HAL or NM suddenly
> needs to allocated some memory one of the "applications" (e.g. Firefox,
> Abiword) will have to pay for it by getting shot by the OOM killer...
> Yes?

Do you want the box to crash or a server to restart. Your choice. I'd rather
that in the 'I've killed all the apps and its not helped' case we killed the
likely offending service.

> I think we would want to never refuse allocations to the "desktop shell"
> components (e.g. WM, panel, HAL etc.) as long as we have
> "applications" (e.g. Firefox, Abiword) to shoot. Doesn't this make
> sense?

Conceptually yes. I'll have a think about implementation issues.




More information about the olpc-software mailing list