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

[Ivan Krstic]

Krzysztof Kowalczyk wrote:
> Linux stack consists of millions of lines of C code written with 
> desktop pc in mind, targeting specs of at least 1 GHz processor, 0.5
> GB of RAM, gigabytes of hard-drive, and high-resolution screens.

A reasonably snappy blackbox running on a 400 Mhz PII with 64MB RAM
disagrees.

> And the same time it lacks some of the things that proved to be useful
> like good IPC mechanizm or system-wide, standard scripting language
> that can be used to both script the apps and as a high-level language
> for writing large class of apps

Python is getting there, and there's lots of work being done on taking
it even further in that direction.

> No matter how hard you try, you're not going to do a good job at
> scaling this stack down to a reasonable size and it will still lack
> the good features.

I disagree; take a look at what Nokia has done with Maemo on the 770.

To take a step back, though, the OOM discussion seems unnecessarily
complicated to me. While solving the problem "correctly" requires
significant engineering work, I'm not sure the OLPC timeline tolerates a
correct solution; a pragmatic one, if it got us 80% of the way there,
would do just fine.

We have pragmatic solutions available: polling the available amount of
RAM, or passing a notification from the kernel when available RAM drops
below a certain amount will both get the job done. The user can be
presented with the option of choosing an application to close, and the
problem is 80% solved. In the face of an application allocating RAM so
aggressively that it causes an OOM condition before the poller/user were
able to address it, I think there's no harm in letting the OOM killer do
its job. It's a corner case.

-- 
Ivan Krstic <krstic at fas.harvard.edu> | GPG: 0x147C722D