[pypy-dev] exerpt from mail from John Gilmore. How close are we to doing this?

Laura Creighton lac at openend.se
Tue Mar 13 23:32:07 CET 2007

We're discussing OLPC.

<Begin exerpt>

> The PyPy project just got its first OLPC.  (We're doing optimisation
> work for them.)  

What kind of optimization?

One thing I've been looking at for them recently is about dirty pages.
A dirty page is a piece of virtual memory that has been written to since
the last time it was loaded from mass storage (flash in their case).
Since they have no disk drive to swap to, every dirty page will stay 
resident in memory forever, until its process dies.  Whereas any page
that isn't dirty can be thrown away and later re-read from mass storage.

The dynamic linker was making piles of dirty pages, which "prelink" can
avoid.  How many pages does Python dirty while it runs?  And if the
kernel provided a signal that said, "We're running low on memory -- 
please do what you can to release some!", is there anything that the
Python interpreter -- or even higher level Python code -- can usefully
do?  As far as I know, all the interpreter's objects are heap-allocated
and there's no way to ever return ANY of that ram to the kernel.  This
is the kiss of death for a memory-limited machine.

<end Exerpt>

I just didn't want this idea to get lost in the report writing.

More information about the Pypy-dev mailing list