9.1 Proposal: Deailing with Low Memory/OOM

[david at lang.hm]

On Wed, 22 Oct 2008, Deepak Saxena wrote:

> I would like to present a short session and faciliate the follow up
> discussion on and dealing with the memory constraints on our system
> at an application framework level.
>
> From my understanding, there are two situations we are running into
> with low memory that need separate solutions:
>
> 1) A single running application, Browse for example, chews up lots
>   of memory.  The only real solution I can think of to this is to
>   make the applications and underlying libraries leaner and smarter. :)
>
> 2) End users run multiple applications or multiple instances of the
>   same application, quickly chewing up system resources.
>
> I would like to primarilly focus on dealing with (2).
>
> I've done a bit of reading on how other low memory systems (cell phones
> for example) handle running multiple tasks and would like to propose we
> borrow some of these ideas for Sugar.  In Android for example, when a user
> switches between tasks, the framework will tell switched out task to save
> enough state such that it can handle being killed while in the background.
> The user does not know that a background application is dead and on task
> switch back to that application, the framework will restart the application
> and tell it that it should restore state and not do a cold startup.  I need
> to read more of the Android and Sugar docs before I can have a detailed
> proposal but at a high level my proposal is to add similar smarts to our
> framework.  This includes, but is not limited to:
>
> - Adding Sugar APIs to handle cold activity start vs restart from saved
>  state and modifying activites to support these APIs.
>
> - Make the Sugar framework (or some other system component) talk to the
>  kernel's OOM interface (/proc/<pid>/oom) to manage what tasks should be
>  killed and ensure the foreground process does not get killed.
>
> What I'm proposing is a form of cooperative multitasking managed at
> the application framework level instead of the core OS level.

how can the user tell the system that they are switching away from the 
browse to another window becouse they know that browse will take 2 min to 
download and display the page and they want to do other useful stuff in 
the meantime? having the system suspend browse when you switch away from 
it is doing exactly the wrong thing.

that being said, having some signal that means 'you don't have the users 
eyeballs right now, don't waste time on animations/etc' could be useful, 
the problem would be defining what NOT to do when in this mode.

David Lang