On Sun, Sep 13, 2009 at 10:12 AM, David Given <d...@cowlark.com> wrote:
> Yes, but that doesn't really answer my question --- *why* is memory > overcommit used on Android? It's normally used on systems with huge > amounts of swap to make more efficient use of physical memory, but > Android devices don't have any swap. > Linux as a general purpose operating system doesn't work well without memory overcommit. As David says, once you have the ability to mmap files from persistent storage, the kernel -does- have the ability to perform paging to reduce RAM usage. We rely on this heavily in Android: of course all shared libraries are mmapped() as a normal Linux thing, all .apks are mmapped (and these usually contain lots of resources and other things that the app may never touch in one particular run so would be a waste to have in RAM), etc. If you turn off over-commit, I believe Android won't even boot on a G1, because Linux would need to assume that RAM is needed for every mmapped() thing, and we run out of it well before the system is fully up. (And if it does actually make it up to the home screen, it is not going to be able to run enough more to be usable.) You should really think of Android as a general purpose OS for mobile devices, not as an embedded OS. There are a few aspects of how it works that are different than a desktop (because we don't have swap etc) but it is much more like a desktop OS than what one generally thinks of as an embedded OS: it needs to run a fairly arbitrary number of programs at a time, with no clear idea of how many resources they will need to use together, and thus wants as much flexibility as possible in how it uses those resources. > The specific problem I've got here is that an app can successfully > allocate memory which it then can't use. Memory overcommit hides memory > allocation failures from the app. The first the app knows that the > memory isn't available is when the OOM killer terminates it without > warning! > Yep. And this is not really different than any other modern desktop OS, except here we try to terminate the app instead of allowing the system to get into a serious paging state and become unresponsive to the user. Put another way: if you are really using so much memory that the kernel needs to kill your app, you are well past the line of being a good citizen (no more background processes can run, no more background services can run, the world at that point can only revolve around you you you), so you shouldn't be there in the first place. There are some mechanisms like the onLowMemory() callback to tell you when memory is getting tight as a hint to start cleaning yourself up. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
