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