1 <html devsite> 2 <head> 3 <title>Low RAM Configuration</title> 4 <meta name="project_path" value="/_project.yaml" /> 5 <meta name="book_path" value="/_book.yaml" /> 6 </head> 7 <body> 8 <!-- 9 Copyright 2017 The Android Open Source Project 10 11 Licensed under the Apache License, Version 2.0 (the "License"); 12 you may not use this file except in compliance with the License. 13 You may obtain a copy of the License at 14 15 http://www.apache.org/licenses/LICENSE-2.0 16 17 Unless required by applicable law or agreed to in writing, software 18 distributed under the License is distributed on an "AS IS" BASIS, 19 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 20 See the License for the specific language governing permissions and 21 limitations under the License. 22 --> 23 24 25 26 <h2 id="intro">Introduction</h2> 27 28 <p>Android now supports devices with 512MB of RAM. This documentation is intended 29 to help OEMs optimize and configure Android 4.4 for low-memory devices. Several 30 of these optimizations are generic enough that they can be applied to previous 31 releases as well.</p> 32 33 <h2 id="optimizations">Android 4.4 platform optimizations</h2> 34 35 <h3 id="opt-mgmt">Improved memory management</h3> 36 <ul> 37 <li>Validated memory-saving kernel configurations: Kernel Same-page Merging 38 (KSM), and Swap to ZRAM.</li> 39 <li>Kill cached processes if about to be uncached and too large.</li> 40 <li>Don't allow large services to put themselves back into A Services (so they 41 can't cause the launcher to be killed).</li> 42 <li>Kill processes (even ordinarily unkillable ones such as the current IME) 43 that get too large in idle maintenance.</li> 44 <li>Serialize the launch of background services.</li> 45 <li>Tuned memory use of low-RAM devices: tighter out-of-memory (OOM) adjustment 46 levels, smaller graphics caches, etc.</li> 47 </ul> 48 49 <h3 id="opt-mem">Reduced system memory</h3> 50 <ul> 51 <li>Trimmed system_server and SystemUI processes (saved several MBs).</li> 52 <li>Preload dex caches in Dalvik (saved several MBs).</li> 53 <li>Validated JIT-off option (saves up to 1.5MB per process).</li> 54 <li>Reduced per-process font cache overhead.</li> 55 <li>Introduced ArrayMap/ArraySet and used extensively in framework as a 56 lighter-footprint replacement for HashMap/HashSet.</li> 57 </ul> 58 59 <h3 id="opt-proc">Procstats</h3> 60 <p> 61 Added a new Developer Option to show memory state and application memory usage 62 ranked by how often they run and amount of memory consumed. 63 </p> 64 65 <h3 id="opt-api">API</h3> 66 <p> 67 Added a new ActivityManager.isLowRamDevice() to allow applications to detect 68 when running on low memory devices and choose to disable large-RAM features. 69 </p> 70 71 <h3 id="opt-track">Memory tracking</h3> 72 <p> 73 New memtrack HAL to track graphics memory allocations, additional information 74 in dumpsys meminfo, clarified summaries in meminfo (for example reported free 75 RAM includes RAM of cached processes, so that OEMs don't try to optimize the 76 wrong thing). 77 </p> 78 79 <h2 id="build-time">Build-time configuration</h2> 80 <h3 id="flag">Enable Low Ram Device flag</h3> 81 <p>We are introducing a new API called 82 <code>ActivityManager.isLowRamDevice()</code> for applications to determine if 83 they should turn off specific memory-intensive 84 features that work poorly on low-memory devices.</p> 85 <p>For 512MB devices, this API is expected to return <code>true</code>. It can be enabled by 86 the following system property in the device makefile.</p> 87 <pre class="devsite-click-to-copy"> 88 PRODUCT_PROPERTY_OVERRIDES += ro.config.low_ram=true 89 </pre> 90 91 <h3 id="jit">Disable JIT</h3> 92 93 <p>System-wide JIT memory usage is dependent on the number of applications 94 running and the code footprint of those applications. The JIT establishes a 95 maximum translated code cache size and touches the pages within it as needed. 96 JIT costs somewhere between 3M and 6M across a typical running system.<br/> 97 <br/> 98 The large apps tend to max out the code cache fairly quickly (which by default 99 has been 1M). On average, JIT cache usage runs somewhere between 100K and 200K 100 bytes per app. Reducing the max size of the cache can help somewhat with 101 memory usage, but if set too low will send the JIT into a thrashing mode. For 102 the really low-memory devices, we recommend the JIT be disabled entirely.</p> 103 104 <p>This can be achieved by adding the following line to the product makefile:</p> 105 <pre class="devsite-click-to-copy"> 106 PRODUCT_PROPERTY_OVERRIDES += dalvik.vm.jit.codecachesize=0 107 </pre> 108 <h3 id="launcher">Launcher Configs</h3> 109 110 111 <p>Ensure the default wallpaper setup on launcher is <strong>not</strong> 112 using live-wallpaper. Low-memory devices should not pre-install any live wallpapers. </p> 113 114 115 <h2 id="kernel">Kernel configuration</h2> 116 <h3 id="kernel-tuning">Tuning kernel/ActivityManager to reduce direct reclaim </h3> 117 118 119 <p>Direct reclaim happens when a process or the kernel tries to allocate a page 120 of memory (either directly or due to faulting in a new page) and the kernel 121 has used all available free memory. This requires the kernel to block the 122 allocation while it frees up a page. This in turn often requires disk I/O to 123 flush out a dirty file-backed page or waiting for <code>lowmemorykiller</code> to kill a 124 process. This can result in extra I/O in any thread, including a UI thread.</p> 125 126 <p>To avoid direct reclaim, the kernel has watermarks that trigger <code>kswapd</code> or 127 background reclaim. This is a thread that tries to free up pages so the next 128 time a real thread allocates it can succeed quickly.</p> 129 130 <p>The default threshold to trigger background reclaim is fairly low, around 2MB 131 on a 2GB device and 636KB on a 512MB device. And the kernel reclaims only a 132 few MB of memory in background reclaim. This means any process that quickly 133 allocates more than a few megabytes is going to quickly hit direct reclaim.</p> 134 135 <p>Support for a new kernel tunable is added in the android-3.4 kernel branch as 136 patch 92189d47f66c67e5fd92eafaa287e153197a454f ("add extra free kbytes 137 tunable"). Cherry-picking this patch to a device's kernel will allow 138 ActivityManager to tell the kernel to try to keep 3 full-screen 32 bpp buffers 139 of memory free.</p> 140 141 <p>These thresholds can be configured via the framework config.xml</p> 142 143 <pre class="devsite-click-to-copy"> 144 <!-- Device configuration setting the /proc/sys/vm/extra_free_kbytes tunable 145 in the kernel (if it exists). A high value will increase the amount of memory 146 that the kernel tries to keep free, reducing allocation time and causing the 147 lowmemorykiller to kill earlier. A low value allows more memory to be used by 148 processes but may cause more allocations to block waiting on disk I/O or 149 lowmemorykiller. Overrides the default value chosen by ActivityManager based 150 on screen size. 0 prevents keeping any extra memory over what the kernel keeps 151 by default. -1 keeps the default. --> 152 <integer name="config_extraFreeKbytesAbsolute">-1</integer> 153 </pre> 154 155 <pre class="devsite-click-to-copy"> 156 <!-- Device configuration adjusting the /proc/sys/vm/extra_free_kbytes 157 tunable in the kernel (if it exists). 0 uses the default value chosen by 158 ActivityManager. A positive value will increase the amount of memory that the 159 kernel tries to keep free, reducing allocation time and causing the 160 lowmemorykiller to kill earlier. A negative value allows more memory to be 161 used by processes but may cause more allocations to block waiting on disk I/O 162 or lowmemorykiller. Directly added to the default value chosen by 163 ActivityManager based on screen size. --> 164 <integer name="config_extraFreeKbytesAdjust">0</integer> 165 </pre> 166 167 <h3 id="lowmem">Tuning LowMemoryKiller</h3> 168 169 <p>ActivityManager configures the thresholds of the LowMemoryKiller to match its 170 expectation of the working set of file-backed pages (cached pages) required to 171 run the processes in each priority level bucket. If a device has high 172 requirements for the working set, for example if the vendor UI requires more 173 memory or if more services have been added, the thresholds can be increased. </p> 174 175 <p>The thresholds can be reduced if too much memory is being reserved for file 176 backed pages, so that background processes are being killed long before disk 177 thrashing would occur due to the cache getting too small.</p> 178 179 <pre class="devsite-click-to-copy"> 180 <!-- Device configuration setting the minfree tunable in the lowmemorykiller 181 in the kernel. A high value will cause the lowmemorykiller to fire earlier, 182 keeping more memory in the file cache and preventing I/O thrashing, but 183 allowing fewer processes to stay in memory. A low value will keep more 184 processes in memory but may cause thrashing if set too low. Overrides the 185 default value chosen by ActivityManager based on screen size and total memory 186 for the largest lowmemorykiller bucket, and scaled proportionally to the 187 smaller buckets. -1 keeps the default. --> 188 <integer name="config_lowMemoryKillerMinFreeKbytesAbsolute">-1</integer> 189 </pre> 190 191 <pre class="devsite-click-to-copy"> 192 <!-- Device configuration adjusting the minfree tunable in the 193 lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to 194 fire earlier, keeping more memory in the file cache and preventing I/O 195 thrashing, but allowing fewer processes to stay in memory. A low value will 196 keep more processes in memory but may cause thrashing if set too low. Directly 197 added to the default value chosen by ActivityManager based on screen 198 size and total memory for the largest lowmemorykiller bucket, and scaled 199 proportionally to the smaller buckets. 0 keeps the default. --> 200 <integer name="config_lowMemoryKillerMinFreeKbytesAdjust">0</integer> 201 </pre> 202 203 <h3 id="ksm">KSM (Kernel samepage merging)</h3> 204 205 <p>KSM is a kernel thread that runs in the background and compares pages in 206 memory that have been marked <code>MADV_MERGEABLE</code> by user-space. If two pages are 207 found to be the same, the KSM thread merges them back as a single 208 copy-on-write page of memory.</p> 209 210 <p>KSM will save memory over time on a running system, gaining memory duplication 211 at a cost of CPU power, which could have an impact on battery life. You should 212 measure whether the power tradeoff is worth the memory savings you get by 213 enabling KSM.</p> 214 215 <p>To test KSM, we recommend looking at long running devices (several hours) and 216 seeing whether KSM makes any noticeable improvement on launch times and 217 rendering times.</p> 218 219 <p>To enable KSM, enable <code>CONFIG_KSM</code> in the kernel and then add the 220 following lines to your` <code>init.<device>.rc</code> file:<br> 221 222 <pre class="devsite-click-to-copy"> 223 write /sys/kernel/mm/ksm/pages_to_scan 100 224 write /sys/kernel/mm/ksm/sleep_millisecs 500 225 write /sys/kernel/mm/ksm/run 1 226 </pre> 227 228 <p>Once enabled, there are few utilities that will help in the debugging namely : 229 procrank, librank, & ksminfo. These utilities allow you to see which KSM 230 memory is mapped to what process, which processes use the most KSM memory. 231 Once you have found a chunk of memory that looks worth exploring you can use 232 either the hat utility if it's a duplicate object on the dalvik heap. </p> 233 234 <h3 id="zram">Swap to zRAM</h3> 235 236 <p>zRAM swap can increase the amount of memory available in the system by 237 compressing memory pages and putting them in a dynamically allocated swap area 238 of memory.</p> 239 240 <p>Again, since this is trading off CPU time for a small increase in memory, you 241 should be careful about measuring the performance impact zRAM swap has on your 242 system.</p> 243 244 <p>Android handles swap to zRAM at several levels:</p> 245 246 <ul> 247 <li>First, the following kernel options must be enabled to use zRAM swap 248 effectively: 249 <ul> 250 <li><code>CONFIG_SWAP</code></li> 251 <li><code>CONFIG_CGROUP_MEM_RES_CTLR</code></li> 252 <li><code>CONFIG_CGROUP_MEM_RES_CTLR_SWAP</code></li> 253 <li><code>CONFIG_ZRAM</code></li> 254 </ul> 255 </li> 256 <li>Then, you should add a line that looks like this to your fstab: 257 <pre class="devsite-click-to-copy"> 258 /dev/block/zram0 none swap defaults zramsize=<size in bytes>,swapprio=<swap partition priority> 259 </pre> 260 <ul> 261 <li><code>zramsize</code> is mandatory and indicates how much uncompressed memory you want the zram area to hold. Compression ratios in the 30-50% range are usually observed.</li> 262 <li><code>swapprio</code> is optional and not needed if you don't have more than one swap 263 area.</li> 264 </ul> 265 <p>You should also be sure to label the associated block device as a swap_block_device 266 in the device-specific <a href="/security/selinux/implement.html"> 267 sepolicy/file_contexts</a> so that it is treated properly by SELinux.</p> 268 <pre class="devsite-click-to-copy"> 269 /dev/block/zram0 u:object_r:swap_block_device:s0 270 </pre> 271 </li> 272 <li>By default, the Linux kernel swaps in 8 pages of memory at a time. When 273 using ZRAM, the incremental cost of reading 1 page at a time is negligible 274 and may help in case the device is under extreme memory pressure. To read 275 only 1 page at a time, add the following to your <code>init.rc</code>: 276 <pre class="devsite-click-to-copy"> 277 write /proc/sys/vm/page-cluster 0 278 </pre> 279 </li> 280 <li>In your <code>init.rc</code> after the <code>mount_all /fstab.X</code> line, add: 281 <pre class="devsite-click-to-copy"> 282 swapon_all /fstab.X 283 </pre> 284 </li> 285 <li>The memory cgroups are automatically configured at boot time if the 286 feature is enabled in kernel.</li> 287 <li>If memory cgroups are available, the ActivityManager will mark lower 288 priority threads as being more swappable than other threads. If memory is 289 needed, the Android kernel will start migrating memory pages to zRAM swap, 290 giving a higher priority to those memory pages that have been marked by 291 ActivityManager. </li> 292 </ul> 293 294 <h3 id="carveouts">Carveouts, Ion and Contiguous Memory Allocation (CMA)</h3> 295 296 <p>It is especially important on low memory devices to be mindful about 297 carveouts, especially those that will not always be fully utilized -- for 298 example a carveout for secure video playback. There are several solutions to 299 minimizing the impact of your carveout regions that depend on the exact 300 requirements of your hardware.</p> 301 302 <p>If hardware permits discontiguous memory allocations, the ion system heap 303 allows memory allocations from system memory, 304 eliminating the need for a carveout. It also attempts to make large 305 allocations to eliminate TLB pressure on peripherals. If memory regions must 306 be contiguous or confined to a specific address range, the contiguous memory 307 allocator (CMA) can be used.</p> 308 309 <p>This creates a carveout that the system can also use of for movable pages. 310 When the region is needed, movable pages will be migrated out of it, allowing 311 the system to use a large carveout for other purposes when it is free. CMA can 312 be used directly or more simply via ion by using the ion cma heap.</p> 313 314 <h2 id="app-opts">Application optimization tips</h2> 315 <ul> 316 <li>Review <a 317 href="http://developer.android.com/training/articles/memory.html">Managing your 318 App's Memory</a> and these past blog posts on the same topic: 319 <ul> 320 <li><a 321 href="http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html">http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html</a></li> 322 <li><a 323 href="http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html">http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html</a></li> 324 <li><a 325 href="http://android-developers.blogspot.com/2009/02/track-memory-allocations.html">http://android-developers.blogspot.com/2009/02/track-memory-allocations.html</a></li> 326 <li> <a 327 href="http://tools.android.com/recent/lintperformancechecks">http://tools.android.com/recent/lintperformancechecks</a></li> 328 </ul> 329 </li> 330 <li>Check/remove any unused assets from preinstalled apps - 331 development/tools/findunused (should help make the app smaller).</li> 332 <li>Use PNG format for assets, especially when they have transparent areas</li> 333 <li>If writing native code, use calloc() rather than malloc/memset</li> 334 <li>Don't enable code that is writing Parcel data to disk and reading it later.</li> 335 <li>Don't subscribe to every package installed, instead use ssp filtering. Add 336 filtering like below: 337 <pre class="devsite-click-to-copy"> 338 <data android:scheme="package" android:ssp="com.android.pkg1" /> 339 <data android:scheme="package" android:ssp="com.myapp.act1" /> 340 </pre> 341 </li> 342 </ul> 343 344 <h3 id="process-states">Understand the various process states in Android</h3> 345 346 <ul> 347 <li><p>SERVICE - SERVICE_RESTARTING<br/> 348 Applications that are making themselves run in the background for their own 349 reason. Most common problem apps have when they run in the background too 350 much. %duration * pss is probably a good "badness" metric, although this set 351 is so focused that just doing %duration is probably better to focus on the 352 fact that we just don't want them running at all.</p></li> 353 <li><p>IMPORTANT_FOREGROUND - RECEIVER<br/> 354 Applications running in the background (not directly interacting with the 355 user) for any reason. These all add memory load to the system. In this case 356 the (%duration * pss) badness value is probably the best ordering of such 357 processes, because many of these will be always running for good reason, and 358 their pss size then is very important as part of their memory load.</p></li> 359 <li><p>PERSISTENT<br/> 360 Persistent system processes. Track pss to watch for these processes getting 361 too large.</p></li> 362 <li><p>TOP<br/> 363 Process the user is currently interacting with. Again, pss is the important 364 metric here, showing how much memory load the app is creating while in use.</p></li> 365 <li><p>HOME - CACHED_EMPTY<br/> 366 All of these processes at the bottom are ones that the system is keeping 367 around in case they are needed again; but they can be freely killed at any 368 time and re-created if needed. These are the basis for how we compute the 369 memory state -- normal, moderate, low, critical is based on how many of these 370 processes the system can keep around. Again the key thing for these processes 371 is the pss; these processes should try to get their memory footprint down as 372 much as possible when they are in this state, to allow for the maximum total 373 number of processes to be kept around. Generally a well behaved app will have 374 a pss footprint that is significantly smaller when in this state than when 375 TOP.</p></li> 376 <li> 377 <p>TOP vs. CACHED_ACTIVITY-CACHED_ACTIVITY_CLIENT<em><br/> 378 </em>The difference in pss between when a process is TOP vs. when it is in either 379 of these specific cached states is the best data for seeing how well it is 380 releasing memory when going into the background. Excluding CACHED_EMPTY state 381 makes this data better, since it removes situations when the process has 382 started for some reasons besides doing UI and so will not have to deal with 383 all of the UI overhead it gets when interacting with the user.</p></li> 384 </ul> 385 386 <h2 id="analysis">Analysis</h2> 387 388 <h3 id="app-startup">Analyzing app startup time</h3> 389 390 <p>Use <code>$ adb shell am start</code> with the <code>-P</code> or 391 <code>--start-profiler</code> option to run the profiler when your app starts. 392 This will start the profiler almost immediately after your process is forked 393 from zygote, before any of your code is loaded into it.</p> 394 395 <h3 id="bug-reports">Analyze using bugreports </h3> 396 397 <p>Now contains various information that can be used for debugging. The 398 services include <code>batterystats</code>, <code>netstats</code>, 399 <code>procstats</code>, and <code>usagestats</code>. You can find them with 400 lines like this:</p> 401 402 <pre class="devsite-click-to-copy"> 403 ------ CHECKIN BATTERYSTATS (dumpsys batterystats --checkin) ------ 404 7,0,h,-2558644,97,1946288161,3,2,0,340,4183 405 7,0,h,-2553041,97,1946288161,3,2,0,340,4183 406 </pre> 407 408 <h3 id="persistent">Check for any persistent processes</h3> 409 410 <p>Reboot the device and check the processes.<br/> 411 Run for a few hours and check the processes again. There should not be any 412 long running processes.</p> 413 414 <h3 id="longevity">Run longevity tests</h3> 415 416 <p>Run for longer durations and track the memory of the process. Does it 417 increase? Does it stay constant? Create Canonical use cases and run longevity 418 tests on these scenarios.</p> 419 420 </body> 421 </html> 422
