Android memory consumption questions

[geoff.stromberg]

I'm trying to demonstrate that Android runs comfortably in 64MB RAM.
To do so, I run the SDK-1.0 emulator like so:

$ ./emulator -qemu -m 64

My first question is whether this is a realistic demonstration? Are
there any significant differences (in terms of memory consumption)
between what's running in the emulator and what would be running on a
typical phone (let's suppose something like a G1 with only 64MB RAM).

My next question has to do with interpreting where the memory is being
consumed. When I look at total memory using the following command
inside the adb shell:

# cat /proc/meminfo

I see, among other output, the following line:

MemTotal: 62108 kB

That much is expected. What confuses me is the output of:

# top -n 1 -s rss

If I sum up the resident memory listed for each process in the RSS
column, I get much more than 64MB. It's more like 130MB. Am I
misinterpreting the RSS column as physical memory consumed? If not,
then why does it add up to so much more that total memory reported by /
proc/meminfo?

More generally, does anyone else have experience to share regarding
running Android in lower memory configs?

Thanks!

(I hope I picked the right group for this post.)

[Jean-Baptiste Queru]

This properly simulates a situation where the device gives 64MB to the
Android side, but not necessarily a device that has 64MB of total RAM,
since a lot of RAM can be reserved for other processors.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

[Yang, Chen]

My 2 cents on the summed RSS, you have excluded the effect of sharing, that's why you have observed large number than the physical memory. Shared libraries, dex files, many of the preloaded classes by zygote are shared among processes. You can get more precise number regarding the sharing effect from the so called PSS(proportional set size) in the proc entry for every process.
--
Chen
China Runtime Technologies Lab
SSG/SSD/MRTC, Intel

[David Turner]

On Tue, Jan 27, 2009 at 8:03 PM, geoff.stromberg <geoff.s...@gmail.com> wrote:

I'm trying to demonstrate that Android runs comfortably in 64MB RAM.
To do so, I run the SDK-1.0 emulator like so:

   $ ./emulator -qemu -m 64

My first question is whether this is a realistic demonstration? Are
there any significant differences (in terms of memory consumption)
between what's running in the emulator and what would be running on a
typical phone (let's suppose something like a G1 with only 64MB RAM).

it's realistic if you consider a simple device with a single memory-mapped framebuffer,
(i.e. no GPU using its own share of the memory for textures), or that the radio interface
is entirely implemented by a hardware modem (unlike the G1 where the radio subsystem
runs on a separate CPU that eats several dozen MB of physical memory).

for the record, we used to have such a "simple" device as a prototype a long time ago
when developing Android. The system ran quite nice with 32 MB, but the frameworks and
applications were also more basic / less powerful (I doubt you could boot in 32 MB these
days).
 

If I sum up the resident memory listed for each process in the RSS
column, I get much more than 64MB. It's more like 130MB. Am I
misinterpreting the RSS column as physical memory consumed? If not,
then why does it add up to so much more that total memory reported by /
proc/meminfo?

these days, RSS doesn't have anything to do with physical memory. I'm not even sure
you can really define "what amount of memory my process uses" anymore in Linux due
to the way various caching/sharing things work :-)

[Geoff Stromberg]

Thanks for the info everyone.

In case anyone's interested: I tried ratcheting the SDK-1.0 emulator memory down to get a rough idea of a lower bound. I started at 64MB, and stepped down in 4MB increments, each time measuring how long it takes to boot, unlock the screen, show the home screen icons, pull out the app tray, and then close it. My very rough  numbers:

    emulator memory / time taken
    64 MB / 26 seconds
    60 MB / 29 seconds
    56 MB / 28 seconds
    52 MB / 30 seconds
    48 MB / 31 seconds
    44 MB / 32 seconds
    40 MB / 41 seconds
    36 MB / 129 seconds

As for where the physical RAM gets used in a phone like the G1, I see this also came up on another thread:

http://groups.google.com/group/android-platform/browse_thread/thread/d29ed9f6e4e22ae

So on the G1, about 100MB goes to the Linux/Android/Apps stack. And the rest goes to the radio processor, graphics processor... and what else consumes the other 92MB?

With regard to graphics in particular, how much does the functionality and performance of the Android platform rely on a separate graphics processor with its own RAM? That's not a very specific question, but I'd be appreciative of any educated opinions! Thanks.

[Geoff Stromberg]

Whoops, sorry I goofed on the above link. I meant this thread:

http://groups.google.com/group/android-platform/browse_thread/thread/adb2fa9946275b73/8b6dc847323c33fb

[Dianne Hackborn]

I would really like to caution you that I don't think at this point 64 MB is going to be sufficient for a true Android device.  There is a big difference between being able to just boot the system vs. having enough memory to actually do anything else, let alone allowing the user to have at least a few extra third party apps doing things in the background.

With some further work on optimizing memory use, or switching to a QVGA screen (with corresponding smaller assets and frame buffers) when that is supported in the framework, 64MB might be viable.  But probably not at this point.

Just for some perspective: you'll need about 30MB available after the system boots for the browser to run comfortably.

Also keep in mind that these devices have NO swap space, so running out of memory is not just a matter of "oh well things are a bit slower," but more along the lines of the world starting to collapse around you.  The Android architecture does a lot to lessen that impact, but there is a line at which things will fall apart.  At 64MB, you're likely to hit it.

On Wed, Jan 28, 2009 at 10:53 AM, Geoff Stromberg <geoff.s...@gmail.com> wrote:

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[Geoff Stromberg]

Thank you, I appreciate the cautionary advice. I'll try not to read too much into my experimenting with emulator memory settings. FWIW, I did try browsing some large-ish sites (nytimes, cnet, wired, amazon-pc-version) using 64MB emulator memory, and found the experience usable. But that's the emulator...

[Jean-Baptiste Queru]

It starts to get more messy if you also have some background tasks
going on (e.g. playing music) and you use the browser to open multiple
tabs (let's say 4) that each display a large page.

JBQ

On Wed, Jan 28, 2009 at 11:47 AM, Geoff Stromberg

--

[Geoff Stromberg]

If we took away the G1's dedicated graphics processor and corresponding RAM, would we loose only performance? Or would we also necessarily loose some of the application processor's RAM to storing graphics resources that were previously stored in dedicated graphics RAM? (That is, other than the framebuffer, which would obviously need to be allocated in the application processor's RAM, if there were no dedicated graphics.)

It looks like native bitmaps created through an API like BitmapFactory.nativeDecodeByteArray are allocated in the application processor's RAM. Is that indeed the case for all necessary graphics resources?

I want to make sure I'm not missing anything when I try to make the argument that running the emulator with the argument "-qemu -m X" does indeed give a fair estimation of what RAM consumption (again, except the framebuffer) would be like on a device with X MB of RAM -- without any memory being dedicated to a radio or graphics processor.

Thanks everyone for your input so far!

[Dianne Hackborn]

On the G1 all surfaces (window buffers, and the full-screen frame buffer) are allocated in a RAM area separate from that available to Linux applications.  It's not really a matter of removing the graphics accelerator, but just that it could be put there to make more memory available for apps.

In the emulator, though, there is just one block of memory that everything + the kernel shares.  There isn't some magical hidden memory beyond the size you specify.

[blindfold]

How will Android (in the near future) accommodate camera bitmaps? An 8
Mpixel camera already consumes 16 MB at a 2 byte per pixel encoding,
leaving 0 bytes for a camera app. Since the camera can be used by only
one app at a time, I can imagine also reserving a separate memory area
for the (decoded) camera bitmaps, accessible only via a camera API
(properly locked such that apps cannot communicate or steal data via
this separate camera bitmap memory). Then one can also retrieve and
process bitmaps in more modest chunks that fit well in the 16 MB app
heap, and hopefully get rid of one frequent cause of OutOfMemoryError
on the G1.

Thanks

[Tomei Ningen]

I suppose you can go into JNI and make a mmap() call to allocate the
memory that you need.

I think the 16MB size limit applies only to the Java object heap.
Outside of it, you can allocate as much as you want ... unless you're
too greedy and get killed by the OS.

My question is, Android will periodically pick background apps to
kill. What is the criteria? Does it consider some sort of 'total
number of private dirty pages'?

On Jan 29, 12:41 am, blindfold <seeingwithso...@gmail.com> wrote:
> How will Android (in the near future) accommodate camera bitmaps? An 8
> Mpixel camera already consumes 16 MB at a 2 byte per pixel encoding,
> leaving 0 bytes for a camera app. Since the camera can be used by only
> one app at a time, I can imagine also reserving a separate memory area
> for the (decoded) camera bitmaps, accessible only via a camera API
> (properly locked such that apps cannot communicate or steal data via
> this separate camera bitmap memory). Then one can also retrieve and
> process bitmaps in more modest chunks that fit well in the 16 MB app
> heap, and hopefully get rid of one frequent cause of OutOfMemoryError
> on the G1.
>
> Thanks
>
> On Jan 29, 5:16 am, Dianne Hackborn <hack...@android.com> wrote:
>

> > On the G1 all surfaces (windowbuffers, and the full-screen frame buffer)

[Dianne Hackborn]

On Wed, Feb 4, 2009 at 10:45 AM, Tomei Ningen <tomei....@yahoo.com> wrote:

My question is, Android will periodically pick background apps to
kill. What is the criteria? Does it consider some sort of 'total
number of private dirty pages'?

It is described here:

http://code.google.com/android/intro/lifecycle.html

And using more than 16MB on the G1 is not recommended, because that memory really needs to be available for other things.