9.1 Proposal: Deailing with Low Memory/OOM

[Eben Eliason]

On Wed, Oct 22, 2008 at 3:34 PM,  <david at lang.hm> wrote:
> 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.

This info is already available via X, I believe.  You're right; the
HIG doesn't have a section on proper behaviors for this case yet. I
have a ticket open on that, but I haven't had a chance to touch the
HIG in months.

- Eben


> David Lang
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>