A Power Management Scheme Controlling 20 Power Domains for a Single-Chip Mobile Processor

Hattori, Toshihiro; lrita, T.; Itô, Masayuki; Yamamoto, Eiji; Kato, H.; Sado, G.; Yamada, Yusuke; Nishiyama, Kunihiko; Yagi, H.; Koike, T.; Tsuchihashi, Yoshihiko; Higashida, M.; Asano, Hiroyuki; Hayashibara, I.; Tatezawa, K.; Shimazaki, Yasuhisa; Morino, N.; Hirose, Keikichi; Tamaki, Shigeru; Yoshioka, Shinichi; Tsuchihashi, R.; Arai, Norihisa; Akiyama, T.; Ohno, K.

doi:10.1109/isscc.2006.1696282

Cited by 56 publications

(23 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Although our descriptions are based on our understanding of the TI OMAP4, a popular mobile SoC with abundant public information [2], we observe similar hardware support on other SoCs [1,3,4,[13][14][15][16][17].…”

Section: Hardware Pm Infrastructurementioning

confidence: 93%

Automated OS-level Device Runtime Power Management

Lin²,

Wang

et al. 2015

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

Device drivers are responsible for disabling and enabling devices on a Systemon-Chip (SoC) at runtime, a practice known as device runtime Power Management (PM). Based on the observations of drivers and their evolution, we consider it harmful to rely on drivers for device runtime PM.We identify information essential to device runtime PM and show that it can be obtained without involving drivers, either by using a software inference approach atop existing ARM-based SoC, or more efficiently by adding one register bit to each device.We thus propose a structural change to the Linux runtime PM framework, replacing PM code in each driver with one kernel module called the central PM agent. We experimentally show that the central PM agent is as effective as hand-tuned driver PM code.We also present a tool called PowerAdvisor, which analyzes traces generated from execution histories and suggests where to add PM code in driver source code. PowerAdvisor not only reproduces PM code that exists in stock drivers, but also correctly suggests PM code never known before.iii Acknowledgment My sincere gratitude goes to my advisor, Dr. Lin Zhong, for his steadfast support of my research. His enthusiasm and guidance has helped me become a better researcher.

show abstract

Section: Hardware Pm Infrastructurementioning

confidence: 93%

Automated OS-level Device Runtime Power Management

Lin²,

Wang

et al. 2015

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

show abstract

Section: Hardware Pm Infrastructurementioning

confidence: 94%

Automated OS-level Device Runtime Power Management

Lin²,

Wang

et al. 2015

Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

Non-CPU devices on a modern system-on-a-chip (SoC), ranging from accelerators to I/O controllers, account for a significant portion of the chip area. It is therefore vital for system energy efficiency that idle devices can enter a lowpower state while still meeting the performance expectation. This is called device runtime Power Management (PM) for which individual device drivers in commodity OSes are held responsible today. Based on the observations of existing drivers and their evolution, we consider it harmful to rely on drivers for device runtime PM.This paper identifies three pieces of information as essential to device runtime PM, and shows that they can be obtained without involving drivers, either by using a softwareonly approach, or more efficiently, by adding one register bit to each device. We thus suggest a structural change to the current Linux runtime PM framework, replacing the PM code in all applicable drivers with a single kernel module called the central PM agent. Experimental evaluations show that the central PM agent is just as effective as hand-tuned driver PM code. The paper also presents a tool called PowerAdvisor that simplifies driver PM efforts under the current Linux runtime PM framework. PowerAdvisor analyzes execution traces and suggests where to insert PM calls in driver source code. Despite being a best-effort tool, PowerAdvisor not only reproduces hand-tuned PM code from stock drivers, but also correctly suggests PM code never known before. Overall, our experience shows that it is promising to ultimately free driver developers from manual PM.

show abstract

“…Although our descriptions stem from our understanding of the TI OMAP4, a popular mobile SoC with abundant public information [6], we observe similar hardware support on other SoCs [7][8][9][10][11][12].…”

Section: Hardware Support For Power Managementmentioning

confidence: 97%

Device drivers should not do power management

Lin

2014

Proceedings of 5th Asia-Pacific Workshop on Systems

View full text Add to dashboard Cite

We argue that device drivers are not the best place to implement power management policies for components on a system-on-a-chip (SoC). We present empirical evidence that device driver developers are inadequately implementing power management and show the information needed for good power management policies is available outside the device drivers. We implement a software central agent to infer the needed information and accomplish power management without device driver support. We further show that simple hardware support can eliminate the overhead of our approach and extend it to support all SoC components.

show abstract

A Power Management Scheme Controlling 20 Power Domains for a Single-Chip Mobile Processor

Cited by 56 publications

References 1 publication

Automated OS-level Device Runtime Power Management

Automated OS-level Device Runtime Power Management

Automated OS-level Device Runtime Power Management

Device drivers should not do power management

Contact Info

Product

Resources

About