Evolution of Suspend-to-Idle Support in The Linux Kernel
Blemings Labs | Sun 24 Jan 4:40 p.m.–5:25 p.m.
Presented by
-
Rafael maintains the Linux kernel’s power management infrastructure (since 2009) and the core ACPI support code (since 2012). He works at Intel (in the System Software Engineering division) and focuses mainly on the mainline Linux kernel development. Rafael has been actively contributing to Linux since 2005, in particular to the kernel’s suspend/hibernate subsystem, power management in general (ACPI PM, PCI PM, PM-runtime, CPUFreq, CPUIdle, PM QoS, wakeup sources framework etc.), hot-plug infrastructure, ACPI and PCI support and more. Before joining Intel in 2012 he worked at the Faculty of Physics of the University of Warsaw as a lecturer, sysadmin and IT support specialist, and he ran a business of his own as a Linux and IT consultant. Rafael holds a PhD in physics from the University of Warsaw, Poland (2002).
Abstract
Suspend-to-idle is a system-wide suspend variant which in principle does not rely on platform support. The suspend-to-idle control flow does not take non-boot CPUs offline and expects all CPUs to enter idle states through the idle loop, like in the working state of the system. However, it assumes that the scheduler tick will be stopped on all CPUs and the timekeeping will be suspended, which is a source of significant complications. It also expects system wakeup devices selected by user space to be functional and it needs to prevent all of the other interrupt sources from waking up the system. In some cases one interrupt source can signal both wakeup and non-wakeup events, so it is necessary to distinguish the former from the latter. All of that together causes the suspend-to-idle support code in the Linux kernel to be quite complex, especially on systems where ACPI is used, and that code has changed for multiple times in response to additional pieces of information on what is needed coming mostly from the users in the form of problem reports. I will describe the evolution of that code since its inception in 2013 and explain the reasons for making the changes in it.
Suspend-to-idle is a system-wide suspend variant which in principle does not rely on platform support. The suspend-to-idle control flow does not take non-boot CPUs offline and expects all CPUs to enter idle states through the idle loop, like in the working state of the system. However, it assumes that the scheduler tick will be stopped on all CPUs and the timekeeping will be suspended, which is a source of significant complications. It also expects system wakeup devices selected by user space to be functional and it needs to prevent all of the other interrupt sources from waking up the system. In some cases one interrupt source can signal both wakeup and non-wakeup events, so it is necessary to distinguish the former from the latter. All of that together causes the suspend-to-idle support code in the Linux kernel to be quite complex, especially on systems where ACPI is used, and that code has changed for multiple times in response to additional pieces of information on what is needed coming mostly from the users in the form of problem reports. I will describe the evolution of that code since its inception in 2013 and explain the reasons for making the changes in it.