Performance directed energy management using BOS technique Pratap Ramamurthy Ramanathan Palaniappan University of Wisconsin-Madison

Outline Introduction BOS Mechanisms Policies Results Conclusion

Introduction

Introduction Energy consumption in mobile devices and laptops Memory could consume 50% more power than processors Is there hardware support ? RAMBUS devices provide capability

Problem Statement How to save power in memory without hurting performance ? Solution: BOS Estimating the optimal amount of memory based on paging activity. Dynamic resizing of memory !

What is BOS ? BOS – Ballooning in-OS technique Tracks current memory requirements Tracks chip access pattern Powers down memory chips Minimizes power consumption

BOS Mechanisms Ballooning in-OS technique Chip selection Power Down Page Migration Page Reservation Invisible Buddy Chip recovery (Power up) Chip selection Intercept memory accesses

BOS policies Power decision Epoch Chip selection Disk activity, # chips powered on Epoch Time interval between two decisions Chip selection Access pattern

Inferences Operating point balances disk accesses and memory power consumption Cost of thrashing offsets the power saved from a single chip Most media applications do not need the entire RAM Least allocated chips are not the least accessed ones

BOS Architecture Migrate Chip Power Table (CPT) Pin the page Wake up Kpower_d Wait an Epoch Get system parameters Decide to Power off/on Do Nothing ON Recover PowerPages Clear flags & unPin OFF Select Chip Loop all pages in chip Update Chip Power Table (CPT) If occupied Migrate If page is free Pin the page If Locked or reserved Wait & Pounce

BOS Mechanisms

Mechanisms In-OS Ballooning Techniques Chip Selection Page Migration Page Reservation Invisible Buddy Chip Recovery Chip Selection Intercept Memory Accesses No Actual Power Down

So replace page using LRU… Power down Selected Chip 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 Under Memory pressure ??? DISK So replace page using LRU… And Migrate!

Page Migration When to migrate ? Kinds of pages File pages Anonymous pages Swap cache pages Free Pages

Page Migration Mechanism Data Transfer Reverse map (thanks to Linux Kernel 2.6) Remap Dependant data structures Page Table Active LRU and Inactive LRU Page cache Swap cache Buffers Flags

Page Migration Major Data Structures Updated while Migrating Processes 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 Buffers LRU lists 1010101010 1010100010 1010001010 1010101010 1010100010 1010001010 1. Memcopy 2. Remapping using rmap 3. Update buffers 4. Remove from LRU lists

Page Reservation Ways to Pin pages Remove from LRU Lists Reserve Page Lock Page Page count

Free Pages Buddy allocator List of free pages Buddy Order (0-11) Locality How to deal with already free pages?

Invisibility in Action (Buddy allocator) 2 1 Make the ‘power’ pages invisible Request for a free page of order 0 Request for a page of order 1 (Invisibility in action)

Invisible Buddy Power Bit Invisibility – divert page allocation Other methods? Why not always remove the page completely from the buddy allocator? Because the free pages are not necessarily in the buddy

Recovery Page in the buddy Pages that were migrated Reverse Recovery Clear power bit That’s it ! Pages that were migrated Clear Power bit Add to the buddy Reverse Recovery Recover the last pinned page and move backwards

Partial Recovery Why would you abort a chip? Easy solution Locked pages Reserved pages IO activity Easy solution Abort chip Better solution Wait and Pounce

Policies

Policy Epoch Power decision Chip select Time interval between two decisions Power decision Disk activity, # chips powered on Chip select Access pattern

Chip Selection Mechanism Chip pattern table Access history over 32 epochs Form a number with the bits and Select the minimum ! How to monitor chip access ? Referenced bit in h/w Clear bits Examine every epoch 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 The least accessed chip is # 6 The least accessed chip is # 7

Results

Results

Chip access pattern

Results # Off Available Memory (MB) 512 10 352 15 272 20 192

Results

BOS architecture Migrate Chip Power Table (CPT) Pin the page Wake up Kpower_d Wait an Epoch Get system parameters Decide to Power off/on Do Nothing ON Recover PowerPages Clear PowerBit & unPin OFF Select Chip Loop all pages in chip Update Chip Power Table (CPT) If occupied Migrate If page is free Pin the page If Locked or reserved Wait & Pounce

Power down/up decision If ( # disk_access < α ) power_down() elseif ( # disk_access > β ) power_up() elseif (α < # disk_access < β ) take_no_action() α, β – thresholds, α < β

Results

Results Other workloads Application # chips ON Memory used Xmms Mp3 player 7 112 MB Totem media player (X-server) 25 400 MB Mozilla,X-server, Open-office (together) 12 192 MB

Conclusion

Conclusion BOS technique is feasible BOS helps us to vigorously control memory size Chip allocation and access pattern have no correlation Several applications do not require the full memory Threshold based policy gives reasonable performance An incorrect chip select could increase migration overhead

Summary BOS philosophy Implementation of BOS Mechanism Policy Page migration Invisible buddy Chip recovery Chip access pattern Policy Study of sample workloads Threshold based policy

Acknowledgements lxr.linux.no We would like to thank the following people for their valuable time and for the immensely helpful discussions in the course of this project Remzi H. Arpaci-Dusseau Muthian Sivathanu Vijayan Prabhakaran Lakshmi Bairavasundaram Amit Jhawar for resources

?

References Huang et.al. “Design and Implementation of Power-Aware Virtual Memory”, USENIX 2003. Lebeck et.al. “ Power Aware Page Allocation”, ASPLOS 2000. Li et.al. “Performance directed energy management for main memory and disks”, ASPLOS 2004. Delaluz et.al. “Scheduler-Based DRAM Energy Management”, DAC 2002.

Related Work Power Aware Virtual Memory [1] Per process chip select Localized per process page allocation Performance not considered Execution Time based energy management [ref] Hardware support for energy management Various power modes in RAMBUS Various power modes in disks

Tough nuts to crack Absolutely no Documentation for Linux 2.6 memcpy() Alternate recovery mechanism Multiple chip select policy Alternate Allocator mechanism Removing from LRU