Table of Contents
Fetching ...

Ariadne: A Hotness-Aware and Size-Adaptive Compressed Swap Technique for Fast Application Relaunch and Reduced CPU Usage on Mobile Devices

Yu Liang, Aofeng Shen, Chun Jason Xue, Riwei Pan, Haiyu Mao, Nika Mansouri Ghiasi, Qingcai Jiang, Rakesh Nadig, Lei Li, Rachata Ausavarungnirun, Mohammad Sadrosadati, Onur Mutlu

TL;DR

Mobile devices face memory pressure that makes relaunch latency and CPU usage critical. Ariadne introduces hotness-aware data organization, size-adaptive compression, and proactive decompression to differentiate hot, warm, and cold data and prefetch next-data in memory. On Google Pixel 7 with Android 14, Ariadne reduces application relaunch latency by about 50% and lowers compression/decompression CPU usage by roughly 15% compared with ZRAM, approaching DRAM-like performance in many cases. The work demonstrates significant practical improvements and provides open-source implementations for replication and further research.

Abstract

Growing application memory demands and concurrent usage are making mobile device memory scarce. When memory pressure is high, current mobile systems use a RAM-based compressed swap scheme (called ZRAM) to compress unused execution-related data (called anonymous data in Linux) in main memory. We observe that the state-of-the-art ZRAM scheme prolongs relaunch latency and wastes CPU time because it does not differentiate between hot and cold data or leverage different compression chunk sizes and data locality. We make three new observations. 1) anonymous data has different levels of hotness. Hot data, used during application relaunch, is usually similar between consecutive relaunches. 2) when compressing the same amount of anonymous data, small-size compression is very fast, while large-size compression achieves a better compression ratio. 3) there is locality in data access during application relaunch. We propose Ariadne, a compressed swap scheme for mobile devices that reduces relaunch latency and CPU usage with three key techniques. 1) a low-overhead hotness-aware data organization scheme aims to quickly identify the hotness of anonymous data without significant overhead. 2) a size-adaptive compression scheme uses different compression chunk sizes based on the data's hotness level to ensure fast decompression of hot and warm data. 3) a proactive decompression scheme predicts the next set of data to be used and decompresses it in advance, reducing the impact of data swapping back into main memory during application relaunch. Our experimental evaluation results on Google Pixel 7 show that, on average, Ariadne reduces application relaunch latency by 50% and decreases the CPU usage of compression and decompression procedures by 15% compared to the state-of-the-art ZRAM scheme.

Ariadne: A Hotness-Aware and Size-Adaptive Compressed Swap Technique for Fast Application Relaunch and Reduced CPU Usage on Mobile Devices

TL;DR

Mobile devices face memory pressure that makes relaunch latency and CPU usage critical. Ariadne introduces hotness-aware data organization, size-adaptive compression, and proactive decompression to differentiate hot, warm, and cold data and prefetch next-data in memory. On Google Pixel 7 with Android 14, Ariadne reduces application relaunch latency by about 50% and lowers compression/decompression CPU usage by roughly 15% compared with ZRAM, approaching DRAM-like performance in many cases. The work demonstrates significant practical improvements and provides open-source implementations for replication and further research.

Abstract

Growing application memory demands and concurrent usage are making mobile device memory scarce. When memory pressure is high, current mobile systems use a RAM-based compressed swap scheme (called ZRAM) to compress unused execution-related data (called anonymous data in Linux) in main memory. We observe that the state-of-the-art ZRAM scheme prolongs relaunch latency and wastes CPU time because it does not differentiate between hot and cold data or leverage different compression chunk sizes and data locality. We make three new observations. 1) anonymous data has different levels of hotness. Hot data, used during application relaunch, is usually similar between consecutive relaunches. 2) when compressing the same amount of anonymous data, small-size compression is very fast, while large-size compression achieves a better compression ratio. 3) there is locality in data access during application relaunch. We propose Ariadne, a compressed swap scheme for mobile devices that reduces relaunch latency and CPU usage with three key techniques. 1) a low-overhead hotness-aware data organization scheme aims to quickly identify the hotness of anonymous data without significant overhead. 2) a size-adaptive compression scheme uses different compression chunk sizes based on the data's hotness level to ensure fast decompression of hot and warm data. 3) a proactive decompression scheme predicts the next set of data to be used and decompresses it in advance, reducing the impact of data swapping back into main memory during application relaunch. Our experimental evaluation results on Google Pixel 7 show that, on average, Ariadne reduces application relaunch latency by 50% and decreases the CPU usage of compression and decompression procedures by 15% compared to the state-of-the-art ZRAM scheme.

Paper Structure

This paper contains 21 sections, 15 figures, 5 tables.

Figures (15)

  • Figure 1: Data movement flow for compression and decompression when using ZRAM in Android systems. Ai (e.g., A1, A2) represents an uncompressed anonymous page of an application. Block B2&C4 refers to a compressed block that includes the compressed data of pages B2 and C4.
  • Figure 2: Application relaunch latency under different memory swap schemes.
  • Figure 3: CPU usage of the memory reclamation procedure (i.e., kswapd) across different swap schemes.
  • Figure 4: Proportion of hot, warm, and cold data in each part of compressed data. We sort all compressed data in the order of compression time and then divide it into ten equal parts (X-axis). The data in part 0 is the first to be compressed, that in part 8 is the last.
  • Figure 5: Hot Data Similarity and Reused Data between two consecutive relaunches of an application across different applications.
  • ...and 10 more figures