Software Engineering

SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Device

By Geunsik Lim Samsung Research
By MyungJoo Ham Samsung Research

Abstract

Existing memory reclamation policies on mobile devices may be no longer valid because they have negative effects on the response time of running applications. In this paper, we propose SWAM, a new integrated memory management technique that complements the shortcomings of both the swapping and killing mechanism on mobile devices and improves the application responsiveness. SWAM consists of (1) Adaptive Swap that performs swapping adaptively into memory or storage devices and manages the swap space dynamically, (2) OOM Cleaner that reclaims shared object pages in the swap space to secure available memory and storage space, and (3) EOOM Killer that terminates processes in the worst case and chooses processes to be terminated by estimating the initialization cost of corresponding applications. Experimental results demonstrate that SWAM significantly reduces the number of applications killed by OOMK (6.5x lower), and improves application launch time (36% faster) and response time (41% faster), compared to the conventional schemes. To make it practical and academically valuable simultaneously, this paper not only verifies the effectiveness of our proposed techniques on actual mobile devices, but also identifies novel ideas that can be reused in other systems in general.

Introduction

Today, as the memory capacity in general-purpose computing systems may not scale to memory consumption trends of the contemporary applications, the memory shortage is a well-known factor that negatively affects the overall system performance. For example, deep learning or cloud services in a server environment require a significant amount of memory to perform their memory-intensive operations simultaneously on large amounts of data, and such applications used to reveal memory shortage problems when their operations require peak memory space. Meanwhile, in mobile devices, the memory shortage problem may be more serious because (1) the number of applications that reside in memory increases over time, and (2) the available physical memory space cannot be easily extended to mitigate the problem.

There have been many efforts [2, 3] to mitigate this problem in mobile environments. Operating systems on mobile devices has adopted two types of mechanisms, swapping and killing, since 2008 [1]. In mobile devices, when the allocated memory space becomes around 60%, the ZRAM/Swap secures available memory space by moving occupied memory pages to the swap area on the memory or storage devices. However, these approaches negatively affect application response time when the processes re-access the swapped-out pages; it requires extra time to reload the data into memory. If the allocated memory space gets close to 80% or 90%, Low Memory Killer Daemon (LMKD) and Out-of-Memory Killer (OOMK) start to kill applications to reclaim a large amount of memory space at once; but, it also suffers from slow launch time when a user relaunches the applications killed by LMKD/OOMK. Note that application response/launch time is very important in that it directly affects the user experience in mobile environments where each device is dedicated to each user. Therefore, traditional memory management schemes (e.g., Swap and OOMK) should be revisited and reformed to efficiently address this issue. In this paper, we propose SWAM, which efficiently orchestrates the traditional swapping and killing schemes with three key components. (1) To efficiently handle swapping and eventually to reduce the response time of applications, Adaptive Swap dynamically adjusts swap space and provides two independent paths for swapping: the fast path which performs swapping onto memory and the slow path which performs it onto underlying storage devices. (2) To secure the available swap space of SWAM, OOM Cleaner preferentially reclaims the swapped-out SO pages that include the contents of shared object (.so) files of each application (we call this swap-clean in this paper). (3) To reduce application launch time, EOOM Killer, which operates based on the mechanism of traditional OOMK, effectively kills the applications with the shorter restart time among the running applications by getting the relaunch cost of SO-symbol lookup and XML-UI conversion as to their restart time.

Background

Generally, the Linux kernel reclaims pages (in the order of anonymous page, buffer, dentry, inode, and process) when the memory space for new allocation is insufficient. In Linux, the Kernel Swap Daemon (KSWAPD) is responsible for reclaiming the memory region that is being used by applications (i.e., pages). The KSWAPD wakes up periodically, and when the amount of memory space in use exceeds a predefined threshold, it begins memory space reclamation. In spite of the efforts of KSWAPD, if the available memory space is still insufficient, the kernel inevitably runs OOMK that scans victim processes and kills them to reclaim the whole memory space belonging to them. Meanwhile, the Android platform adopts and exploits more reclamation steps over the Linux kernel because of the limited hardware resources of mobile devices; each step is triggered in the order of ZRAM, Swap, LMKD, and OOMK.

Observation

In this section, we introduce three kinds of major performance impacts with the explanation on the related side effects. To deep dive into the behaviors of traditional swapping and killing operations, we conducted various evaluations while collecting raw data using dumpstate, dumpsys, and adb commands. First, we conducted evaluations on four popular commercial mobile devices (e.g., Samsung Galaxy S9+, S10, S20, and S21) in manufacturers’ initial states to understand the overheads caused by the memory shortage problem.

Figure 1.  The three performance impacts (i.e., response time, memory usage, initialization latency) with 4 sources (e.g., swap, memory, SO, and XML) caused by conventional swapping and killing operations

Figure 1 shows the average performance impacts measured on the four commercial mobile devices. We measured the response time of applications (Figure 1(a)) and the total memory usage of applications (Figure 1(b)) when the available memory space is insufficient with the boot-up step. Next, we measured the latency derived from the SO-symbol lookup (Figure 1(c)) and XML processing (Figure 1(d)) by running top-ranked representative applications from Google Play Store. We first targeted 15 top-ranked representative applications to assure evaluation reliability, because the evaluation results may be different according to the design structure of SO and the operation pattern of XML-UI. To the best of our knowledge, the cost of Global Offset Table (GOT) entry and Symbol lookup is strongly dependent on the design structure of SO files. Therefore, for SO-symbol lookup experiment (Figure 1(c)), we additionally selected 45 applications from Google Play Store to investigate a wider range of applications. In summary, we targeted about 60 applications since the creation cost of GOT entry and Symbol lookup is diverse according to the design structure of SO files, and Figure 1(c) shows our test results on average. Finally, we studied the XML-UI operation patterns based on 15 representative applications that use the UI interfaces intensively (Figure 1(d)). These observations and experimental results motivate us to explore the design of SWAM.

Design and Implementation

Figure 2.  System overview of SWAM

To alleviate the overheads while preserving the benefits of existing schemes (ZRAM, Swap, LMKD, and OOMK), we propose a new memory monitor and management scheme, SWAM, for modern mobile devices. The design goal of SWAM is to (1) reduce the launch time and response time of applications by orchestrating the behaviors of ZRAM and Swap mechanisms, (2) efficiently reclaim the memory space occupied by applications based on both the process attributes and access patterns, and (3) postpone killing applications as long as possible while optimizing it with the help of launch time estimation.

In order to introduce the concept of SWAM before going further, Figure 2 shows the architectural overview of SWAM, which is composed of Adaptive Swap, OOM Cleaner, and EOOM Killer. As indicated in the figure, Adaptive Swap simultaneously handles the zram-out/swap-out procedure for achieving efficiency and better performance based on the characteristics of not only SO pages but also normal pages (see blue lines). OOM Cleaner secures enough free space for swap operations without killing applications (see green lines). Finally, EOOM Killer identifies victim applications that can be quickly re-launched based on the hints of the Launching Cost Manager and kills then in the worst case (see red lines). In our full paper, we describe in detail how SWAM, a novel mobile-aware memory management scheme motivated by our observations, complements the shortcomings of conventional swapping and killing mechanisms.

Evaluation

In this section, we evaluate SWAM with the popular mobile applications so as to answer the following research questions: (RQ1) how does each individual effort in SWAM help with taking care of the available memory space and (RQ2) how well does SWAM perform on the whole with modern mobile devices? We implemented the prototype of SWAM in Linux kernel version 5.10 and Android Open-Source Project (AOSP) 12; the total of 7,250 lines of code were added or modified. We also used real world applications (top 15 applications from Google Play Store) that are frequently employed. The behavior of swapping and killing approaches significantly depends on memory capacity, and therefore, to investigate the possible impact of SWAM on limited hardware resources, We compared SWAM with two baselines where the original LMKD/OOMK is already enabled; (1) ZRAM with 1 GB memory for swap space and lz4 algorithm for (de)compression, and (2) NAND-swap with 3 GB swap partition reserved on the underlying storage device. From our experiment, even when a mobile device is under memory pressure, it may provide faster application launch time (36% faster) and faster response time (41% faster) than the conventional schemes, which shows significant positive impact on user experiences.

Conclusion

We carefully revisit the conventional memory management techniques in mobile platforms. We highlight the structural limitations of the traditional swapping and killing mechanisms which operate independently, and propose a state-of-the-art memory management technique that complements the traditional schemes. We collaborated on this research with Donghyun Kang (Garchon University) and Young Ik Um (Sungkyungkwan University).

Link to the paper

Geunsik Lim, Donghyun Kang, MyungJoo Ham, and Young Ik Eom, "SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices," MobiCom (29th Annual International Conference On Mobile Computing And Networking), 2023.

Mobicom 2023 : https://sigmobile.org/mobicom/2023/accepted.html
Paper link : https://arxiv.org/abs/2306.08345

References

[1] J. F. Kurose. “Research Challenges and Opportunities in a Mobilitycentric World,” In Mobicom (2015)

[2] N. Lebeck, et al. “Killing: Improving Memory Management for Mobile Operating Systems,” In ATC (2020)

[3] S. S. Hahn. “Fasttrack: Foreground App-aware I/O Management for Improving User Experience,” In ATC (2018)