9.1 Proposal: Deailing with Low Memory/OOM
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. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Deailing with Low Memory/OOM
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Deailing with Low Memory/OOM
On Wed, Oct 22, 2008 at 09:44:50AM -0700, 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. :) Instead of tweaking everything to run in a tiny box, you could use compcache and change the shape of the box the apps are stuck in. For the past week I've been running all my XOs with compcache (http://code.google.com/p/compcache/)--- a kernel module which can be used to create a ram-backed lzo-compressed swap partition. I have had no negative experiences which are overtly related to running compcache (I run a 100mb compcache). My impression is that I can run more activities than before without running into low memory situations. I am currently testing this assumption more rigorously using LTP (linux test project). Compcache relieves memory pressure enough that I can run xcompmgr without reducing the number of activities I typically run concurrently (4-5) on an XO without compressed memory caching. X composite greatly improves the UI responsiveness on the XO and makes it much more of a pleasure to use. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
