Tags

In bug 1062365, I have been trying to get our Firefox for Android tests running for a new platform, Android 4.4. Like the Android 2.3 tests, these will run on the Android arm emulator, hosted on aws; they will just be run on the much newer Android 4.4.

I recently noticed that some 4.4 test failures were related to Firefox for Android’s low memory handling: To allow for operation on low memory devices, some Firefox features behave differently when Android reports that the total memory on the device is below a certain threshold.

But my test failures were quite unexpected: I was configuring the emulator AVD with more than 1 GB of memory — much higher than the “low memory” threshold. What was going on?

Firefox for Android’s notion of a “low memory” vs a “high memory” device is based on the MemTotal reported in /proc/meminfo. If you configure an Android emulator to run Android 4.4, request a RAM size of 256 MB and then cat /proc/meminfo, you will see a MemTotal of approximately 256 MB:

MemTotal:         253904 kB

If you modify your emulator avd configuration to request a RAM size of 512 MB and cat /proc/meminfo, you will see a MemTotal of approximately 512 MB. That seems reasonable and expected.

But if you request 1024 MB, you will see:

MemTotal:         765372 kB

What!?

If you request 2048 MB, you will still see:

MemTotal:         765372 kB

You might be tempted to try setting the “-memory” command line option when starting the emulator, or passing “-qemu -m …” to request more memory in qemu, but none of that will help: Android will stubbornly refuse to acknowledge anything more than 765372 kB of memory.

Thankfully dmesg provided a clue about the missing memory:

Truncating RAM at 00000000-7fffffff to -2f7fffff (vmalloc region overlap).
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
      .text : 0xc0008000 - 0xc044a190   (4361 kB)
      .init : 0xc044b000 - 0xc0470000   ( 148 kB)
      .data : 0xc0470000 - 0xc04a8fc0   ( 228 kB)
       .bss : 0xc04a9000 - 0xc05f33c8   (1321 kB)

In the words of http://www.embedded-bits.co.uk/2011/vmalloc-region-overlap/, this is the kernel’s way of saying “I understand there may be some RAM here – but I’m not going to use it all”. That article gives a great description of what is happening and possible ways of accessing the extra RAM — I won’t regurgitate all the details here. It suggests that one way of using additional memory is to use a kernel configured with CONFIG_HIGHMEM.

I checked some Android kernels and found that several are normally built with CONFIG_HIGHMEM — but not the “goldfish” kernel, used in the Android emulator. I rebuilt the goldfish kernel, with CONFIG_HIGHMEM defined and installed the new kernel in my avd. Now, requesting 1536 MB in the avd configuration, I see:

MemTotal:         1537336 kB

Perfect!

How much memory should we configure the emulator to use when running Firefox tests? That’s an open question still. 765 MB seemed restrictive and out of step with the RAM found on many modern Android devices, so I’m glad to have a choice now, and interested in determining if the additional memory will help the performance of our tests, or resolve any known failures.

Great thanks to :snorp for helping me track down my “missing memory” and understand all of this!

The curious will find more context in bug 1128548.

Advertisements