System Suspend Support in the Linux Kernel 2007 - 2017
Rafael Wysocki
http://lca2018.linux.org.au/schedule/...
System suspend is relatively straightforward from the user perspective.
When requested, it should put the whole system into a state with all
activity stopped and reduced power draw. Next, the system should wait
in that state for an event to wake it up and then go back to its previous
state and get on with whatever it was doing before, ideally without any
side-effects visible to the user. The implementation of that in an
Operating System, however, turns out to be seriously complicated.
First of all, stopping all activity in a multiprocessor system, like
a modern laptop, is a rather tricky business and it cannot take too
much time, or it will not be appreciated by users. On top of that,
in general, all devices in the system need to be put into low-power
states, so that the total power draw of the suspended system can be
as low as expected and that should happen quickly too. Still, some
devices need to remain sufficiently active to be able to wake up the
system when needed and that has to be taken into account along with
all of the possible dependencies between devices. Moreover, the time
it takes for the system to get back to the working state also cannot be
too long and, finally, all of the above must be absolutely reliable
or system suspend will not be used. Combined, all of these items
may look a bit intimidating.
Of course, that did not prevent Linux kernel developers from implementing
system suspend support, but it took quite some time to reach the current
state of the art. Various parts of the suspend infrastructure have been
under development for several years, but it started to be recognized as
a separate feature in 2007.
Overall, a lot of progress has been made and nowadays system suspend
in Linux is regarded as one of the features that generally should work.
There are gaps in it and occasional regressions happen, but also there
is a huge number of Linux-based systems in the field that suspend
reliably on a very regular basis. However, it is instructive and
somewhat entertaining to look back at where we started and how we
have got where we are today.
That leads to some interesting observations. One of them, which seems to
be particularly important to me, is that improvements are made by iterating
three basic steps again and again. First, we get some better understanding
of what really happens, either by diagnosing reported issue or by adding
support for new technologies. That better understanding results in code
improvements which typically unlock some use cases that were not viable
previously. Next, the new use cases are exercised and become the source
of feedback which then causes our understanding of things to get better
still and a new cycle begins. Every iteration takes us to the next level
and progress is made this way.
That pattern is clearly visible in the history of the development of
system suspend support in Linux, but it is not the only thought-provoking
aspect of it as I will show in my presentation.
This talk was given at Linux.conf.au 2018 (LCA2018) which was held on 22-26 January 2018 in Sydney Australia.
linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/
#linux.conf.au #linux #foss #opensource