idea for running out of RAM

[Bobby Powers]

On Tue, Sep 23, 2008 at 3:40 AM, Albert Cahalan <acahalan at gmail.com> wrote:
> 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.

ugh, I know this is a frustrating area in general, but how
easy/intuitive is it for kids if they are running one activity for
another activity to fail to launch because it has (or doesn't have)
RAM requirements listed?


setting RAM requirements reminds me of classic macos :)

bobby


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