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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel