9.1 Proposal: Deailing with Low Memory/OOM
eben.eliason at gmail.com
Thu Oct 23 10:07:25 EDT 2008
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.
> David Lang
> Devel mailing list
> Devel at lists.laptop.org
More information about the Devel