idea for running out of RAM

[Erik Garrison]

Deepak,

Did you continue down this path (auto-saving application state to NAND
when we run out of memory)?  How tenable is the idea of saving
application state to NAND on our system?

Could the oom-killer have a hook to enable this functionality to be
invoked instead of simply killing the application?

Erik

On Tue, Sep 23, 2008 at 10:57:36AM -0700, Deepak Saxena wrote:
> On Sep 23 2008, at 03:40, Albert Cahalan was caught saying:
> > 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)
> 
> I like the idea overall but this part worries me. An activity such
> as etoys has a lot of 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.
> 
> I've been thinking to myself that this might be the right approach. While
> we may think of that as limiting, for a child who has never used a computer
> before, it might help focus their attention and be less confusing to 
> simply allow one instance of any activity to run.
> 
> We can also play tricks like saving state of an activity to flash on
> alt-tab and quickly restoring it when tabbing back. This is common 
> in the mobile space where we want an illusion of being able to switch
> between running applications. Your cellphone will most probably
> never crash due to OOM, but you can often run multiple applications
> on it. This won't work with shared activities or activities that 
> have any network sockets open, but for purely local applications
> it should be do-able (though non-trivial).
> 
> Something else I am looking into for helping with memory on 8.2.1 and 
> 9.1 is compressed caching. We can still OOM with this, but my experience
> with my little playing I've done with it is that it drastically helps
> keep the system useable as memory footprint increases.
> 
> ~Deepak
> 
> -- 
> Deepak Saxena - Kernel Developer - dsaxena at laptop.org
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel