idea for running out of RAM

[Albert Cahalan]

For the zillionth time, my kids brought my XO to a halt. They started
up two copies of Tux Paint and two copies of Colors! (BTW, boy do I
hate names with built-in sentence-ending punctuation) The end result
is that the activities die (unacceptable), usually via power button.

There are a number of different problems here. It's a UI defect that
the kids lose track of what is running and feel a need to start things
that are already running. Kids don't think "I **switched** back to the
home screen". Instead, they seem to think "the activity suddenly died".
It's another UI defect that they are getting switched away from the
activity at all; I'm quite sure there is no intent to go to the home
screen. It just happens randomly, being not very kid-friendly.

Intentional or (more likely) not, the kids get too many things running.
In theory the kernel will kill things as a last resort, which is awful,
but it doesn't happen because the user won't wait (hours? days?) for it.

Fully solving the problem is impossible, but we can do a lot better.
First let's rule some things out:

* the slow hang we have, causing loss of work via power button
* OOM, causing loss of work via actively killing stuff
* rlimit, causing loss of work via allocation failure
* activity grabs RAM up front, leading to one of the above

The commonality here is that, once started, an activity must never
be bothered with a memory shortage.

We can cover nearly all cases with RAM reservations. Worrying about
the other cases is not productive. Activities can lie about how much
RAM they will use. The OS itself may unexpectedly consume RAM. Again,
a perfect 100% solution is impossible but we can do a decent job.

RAM reservations go in activity.info files. They let sugar know
when to stop letting the user start new activities.

Suppose we have 256 MB, the OS consumes 176 MB, and 80 MB is left.
Activity X declares a need for 60 MB, activity Y declares a need
for 20 MB, and activity Z declares a need for 30 MB. Activities
P and Q do not declare anything. The user may thus run any of:

X
X,Y
Y,Y,Y,Y
Y,Y,Y
Y,Y
Y
Z
Z,Z
Z,Z,Y
Z,Y,Y
Z,Y
P
Q
P,...,P,Q,...,Q (unlimited)   <-- optional

If we allow that last option, then activities P and Q are unprotected
in every way. Any number of them can run at the same time. Crashing is
far more likely, which is bad, but existing behavior is preserved.

Note that activities which declare a RAM requirement will never run at
the same time as activities which do not. If this is allowed, then any
activity that fails to declare a RAM requirement will endanger data in
the well-behaved activities. It's an option, but a rather awful one.

To be clear: after starting 4 copies of activity Y, sugar must refuse
to start any more. It's simply not allowed, since doing so is likely
to lead to data loss.

Not every activity can declare a RAM requirement. I happen to know that
Tux Paint is fairly well behaved; it does not grow without bound.
I strongly doubt that Browse is well-behaved or ever could be.

Determining the RAM requirement for an activity goes something like
the following:

awk '/Dirty/{x+=$2} END{print x}' < /proc/12345/smaps

(after exercising all functionality)

We can refine that, remembering that it will never be perfect.
Adding a bit more (5 megabytes?) to avoid the slows is important.

If an activity has lied, there isn't much that can be done. Oh well.
If the lie is caught before the system gets horribly slow, the OS
can simply increase the reservation for that activity. (either just
for that session, or persistently) The OS can log the problem, allowing
the activity developer to be flamed. Killing the lying activity is not
a good option, but it could be done, especially if some other activity
is already running. Once the slows hit, it's back to the power button.

BTW, the alternative is far more harsh yet easier for kids to deal with.
We just ditch the whole idea of letting activities run concurrently. :-)
Seriously, consider it. We're really short on RAM, and activity switching
is not at all easy for kids.