After developing a tool to visualize RAM and zRAM in Android, I discovered that there is intense competition for resources in phones. And if the process needs resources that are already occupied by someone else, it will take them away, which can lead to critical situations and equipment conflicts.

Have you ever used such utilities as htop, top, vmstat? If you have Linux installed at all, then most likely yes. And they do a really good job of showing OS resource usage statistics. I researched operating systems, and I lacked an understanding of what the physical address space really looks like: which particular addresses are occupied, which are free, what happens if processes request the same addresses, how often this happens.

There was a hypothesis that in Android (and in Linux), there is an active competition for resources. Spoiler from the title of the article: it was confirmed.

I have developed an application that visualizes the location of processes in memory on Android phones. Data is read for each memory page for the selected process. This data can also be further processed. The developed tool allows the user to explore both RAM and ZRAM, display the information obtained in a graphical form. The user can select processes from the cgroups tree.

The main application window looks like this. Next, it will be considered the memory card, which is displayed in the center.

A bit of theory

Memory management in Android is part of the functionality of the Linux kernel. The kernel has full access to system memory and allows processes to safely access that memory as needed. Applications require a lot of resources, and therefore diagnostics, analysis, and debugging are used to optimally allocate resources for applications. Understanding the dynamics of memory reallocation can give a much clearer picture of the system. Meanwhile, mobile operating systems have more hardware and software-related limitations compared to desktop operating systems.

Android memory management is organized using 4 KB pages. The kernel keeps track of the state of each page of physical memory present in the system.

I researched memory management methods in Android and Linux and compared the available tools for checking and monitoring memory. There are no tools that could visualize the picture. It is also difficult to interpret numbers, so I entered a quality indicator and displayed the memory map page by page.

apagescan collects memory allocation information across multiple processes, then creates memory snapshots and captures dynamic memory changes. apagescan works with procFS to read any number of pages into RAM, providing information about each page, including the present/swapped/dirty and anon/not anon flags. 

Each page can be in one of the following states:

1. Present / not Present: The current page is mapped to a page in physical memory. If the page is not present, it can be swapped (moved) to disk.

2. Dirty / Clean: Dirty pages are pages that have been modified because they have been paged into physical memory from disk memory and are waiting to be written back to disk. Clean pages are pages that have not been modified by the process.

3. Named / Anonymous: Named blank pages can be restored from a special file. Anonymous pages are supported by the swap partition or physical memory. Anonymous clean pages can be restored from /dev/zero.

Users can also select processes from cgroups to check. cgroups is a mechanism for grouping processes at the kernel level.

Received Snapshots

Three applications were running on the Nexus 5 and used for a total of two minutes while apagescan collected data with a 0 second delay. between measurements. 60 physical memory snapshots were taken. Each square (dot) in the figure is a page in the phone's memory. A thick black line at the bottom of the figures separates the swap partition.

The camera (blue - 5837 PID), browser (fuchsia - 5307 PID) and gallery (green - 5390 PID) applications were used in the experiment. On fig. below is the initial memory state when a browser app was used and other apps were in the background. Most of the RAM is taken up by the browser and much less by the camera and gallery. There are also no pages in the swap area. 

  Figure 1 - Snapshot of physical memory. The browser is in the foreground, the gallery and the camera are in the back.

There were some changes in memory mapping while the browser was running, but these were only noticeable when the browser application went into the background and the camera application was selected (see Figure 2). Some of the pages were replaced by the camera pages, but most of them stayed where they were, and the camera pages just took up space.

 Figure 2 - Snapshot of physical memory. The camera is in the foreground, the gallery and the browser are in the back.

On fig. Figure 3-4 shows the "competition" between the camera and gallery apps (red area) and the page eviction process when the app goes into the background (blue area). That is, the figures show how different applications access the same memory areas (the points on the graphs overlap each other). And testing various applications, allowed me to see that the competition for resources occurs quite often. Especially if there are not very many resources, which, of course, is true for mobile phones.

 Figure 3 - Snapshot of physical memory. The gallery is in the foreground, the camera and browser are in the background.

 Figure 4 - Snapshot of physical memory. The camera is in the foreground, the gallery and the browser are in the background.

conclusions

Knowing about Android's intense memory contention can be useful in both mobile app development and resource scheduling on Android (and Linux). When one process requests resources that are already occupied by someone else, the first process will simply take them away. This can lead to endless context switches during times of low resources, as well as crashes and hardware conflicts. At the same time, identifying how applications compete for resources allows you to optimize the entire system.