idea for running out of RAM

Benjamin M. Schwartz bmschwar at fas.harvard.edu
Sat Nov 1 11:01:56 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Albert Cahalan wrote:
> Memory reservations are a different beast entirely. Running
> out of memory becomes approximately impossible because
> the user is blocked from starting too many activities.

This seems like a silly statement to me.  Almost every activity on the XO
is capable of exceeding the hardware memory limit all on its own.
Per-activity memory reservations are also per-activity limits, and they
are only safe if those limits are set higher than the maximum amount of
memory required by that activity, and that maximum value is simply far too
large.  I like the idea of memory reservations, and they were part of the
original design, but if we set them high enough to be safe, we would have
a single-tasking (and maybe zero-tasking!) operating system.

I should also be clear that I don't think Activities should receive the
low-mem signal.  I think Sugar should catch the low-mem signal, so that it
can attempt to do something smarter than the OOM killer because it knows
much more about the system.  For example, it can choose to kill the
activity instance that is using the most memory, or the
least-recently-used activity instance, or even the instance that has most
recently saved its state.

This works especially well if we also use the knobs on the OOM killer.
For example, the low-mem signal, after pausing all other processes, could
cause Sugar to (1) select an activity to kill, (2) set that activity's
oomadj parameter to make sure that it will be the first one killed if we
hit OOM (3) ask that instance to save its state to the datastore, (4)
close the activity instance, and (5) pop up a notification to the user
about what just happened.

The cgroups stuff could also help here, since the OOM killer by default
thinks in terms of processes, but each Activity can be multiple processes.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkMb2MACgkQUJT6e6HFtqR1SACfafFkA4mYsuasPypMasU1LxN0
QoQAnjUbvkbvAgpQ++5SJDJS1ng5CFjj
=uQeu
-----END PGP SIGNATURE-----



More information about the Devel mailing list