Out-of-memory management in a mobile GNOME device

Hi,

I'd like to attend the GNOME.Asia Summit 2008 and talk about out-of-
memory (OOM) management in a mobile device that is based on the GNOME
platform.

Summary of the proposed talk "Out-of-memory management in a mobile GNOME
device"
--------------------------------------------------------------------------------

Compared to typical Linux desktop PCs, mobile devices have limited
amount of RAM and often don't have the possibility to use paging (aka.
swapping) on to a mass storage to extend amount of virtual memory. There
is also a serious problem of the whole system slowing down when the RAM
is about to run out --- this can lead to very bad usability of the
device. On the other hand, GNOME and other open source has mostly been
designed for desktop PCs and uses lot of memory. The system must have a
mechanism for handling the out-of-memory (or low-RAM) situation.
Basically this means, among other things, that the most important system
processes are kept alive at the expense of less important processes.

The GNOME platform heavily uses the Glib library that does not allow
graceful handling of out-of-memory situations. In the worst case, this
is causing unpredictable crashes everywhere in the system in the case
RAM runs out. The graphical user interface (UI) in applications is
usually implemented using the GTK+ UI toolkit which is based on the Glib
library, as well.

In the Nokia 770 (N800 and N810), we designed a solution which involves
the Linux kernel, D-Bus signals, and the application framework. When the
kernel signals that the amount of memory is getting low, we can shut
down applications that are running in the background to free some memory
and possibly deny starting of new applications, or ask the user to
choose an application to close. Some of this "background killing" of
applications can be nearly invisible to the user because of a mechanism
called "state saving": before closing, the application would save its UI
state into a mass storage, allowing loading of the state and re-creating
of its UI later when the user chooses it as the foreground application.

If the memory gets even more scarce, we have the option to disable some
features in the Web browser to save memory. We had prioritised the
system processes for the kernel's out-of-memory killer for the case that
the memory (RAM) really runs out: the kernel would kill less important
processes first and hopefully leave the system in a state where it is
still usable. We also had the possibility to create a paging file onto
the memory card: the kernel would write infrequently-used memory pages
to the file on the memory card to free up RAM for more important memory
pages.

In this same talk, I'm also planning to briefly talk about the memory management and paging in the Linux kernel, so that also people that are not familiar about the basic concepts could follow the talk.