[Sugar-devel] Killing activities when memory gets short

[John Gilmore]

I didn't do as detailed an analysis as NoiseEHC - I looked at dirty
page frames, and realized that a large part of RAM was filling with
dirtied pages (even dirtied pages of executables, which get patched to
fill in shared library linkages).  Without swap, this left very few
page frames for read-only executable code to live in -- so it would
tend to get paged out (destroyed) on the theory that it's easy to
bring it back in again.  The result was slow execution.

My theory on how to improve on that from the high Python app level was
to have the Python apps save their state when obscured (like Android
apps) and also provide a fast start path from a saved state to a
resumed process in that state.  Any process which had saved its state
this way (probably in a little xml file or binary file -- something
quick and not memory-intensive to parse) could then terminate, which
would free up all of its dirty pages.  When it needed to be visible
again, it would be re-invoked by the shell and would jump to the same
place in the GUI without stirring up a lot of memory references.  This
high level kludge would allow even interpreted Python programs to
effectively reduce their working set.

This strategy was never built and tested, however.  I could barely get
people to look at the /proc/smaps results that pointed to dirty pages
stuck in RAM as the slowness culprit, and was also unsuccessful in
convincing OLPC to prelink the shared libraries before shipping a
release, thus allowing read-only pages to not get dirtied with shared
library linkage relocations.

	John