We're hiring!
*

Lucid sleep in the free desktop

Tomeu Vizoso avatar

Tomeu Vizoso
May 01, 2015

Share this post:

For the past year I have been working on the kernel side to bring some ChromeOS features to upstream.

One of the areas I'm currently working on is what Google calls Lucid Sleep, which is basically the ability of performing work while the machine is in a low power state such as suspend. I'm writing this blog post because there has been interest on this in different communities and the discussion is currently a bit dispersed.

Small mobile devices have been able to do that since basically always and this feature brings it to bigger devices that traditionally have been either on or off. It's similar to what Microsoft calls InstantGo (previously Connected Standby).
Checking if the battery level is so low that it would be better to completely power down the machineA few examples of tasks that the system could perform while apparently sleeping are:
  • Starting a network backup if the present connectivity allows it (a known access point may have become accessible)
  • Downloading email
  • Checking for new instant messages
With regards to functionality and leaving performance considerations aside, userspace could implement this without requiring any new support in the kernel as illustrated in this scenario:
  • We assume that a video is currently playing in YouTube
  • User closes the lid
  • PM daemon notifies userspace of an impending sleep
  • Browser pauses playback
  • Compositor switches off the screen
  • Kernel freezes userspace, suspends devices and puts the CPUs to idle
  • Time passes...
  • RTC alarm fires off
  • Kernel resumes devices and unfreezes userspace
  • Userspace realizes there hasn't been any user activity since it went to sleep last, so stays in "dark resume" mode
  • Userspace does any lucid tasks it wants, then goes back to sleep again
  • Kernel freezes userspace, suspends devices and puts the CPUs to idle
  • Time passes...
  • User opens lid
  • Kernel resumes devices and unfreezes userspace
  • PM daemon notices the SW_LID event, so notifies userspace that this is a full-on resume
  • Compositor switches screen on
  • Browser resumes playback

No changes needed in the kernel is always good news, but there's two issues.

Lost input events

Sometimes the event from the input device that woke the system up gets lost before it reaches userspace, so we don't know if we can stay dark and do our lucid stuff, or if the user expects the machine to power completely on.

This is in any case a bug, but if it needs to be fixed in the firmware, we may not be able to do much about it. At most we could get the kernel to synthesize an input event, but sometimes it may not have enough information to do so.
 

Performance

When the system wakes up, there tends to be a lot to do in the kernel and userspace, so it could take several seconds for the screen to come up from the moment the user opened the lid in the scenario presented above.

For ChromeOS this isn't acceptable so they are carrying some patches in their kernel that make some shortcuts possible (the screen is left on at suspend time, and the kernel knows at resume time whether it has to power it on based on which was the wakeup source, thus not having to wait for userspace).
 
Fortunately, there have been some changes recently in the kernel PM subsystem that can speed up resumes quite a bit and we can make use of them to offset the penalty of dropping those shortcuts.

The first is idling the CPUs instead of suspending to firmware, which on modern SoCs should be quite efficient and much faster, by a few tenths of seconds.

The other is to leave idle devices that are already in a low power state alone when suspending, which means that we don't have to wait for them to resume when the system wakes up. In every system I have seen there's always a few devices that take a long time to resume, so this can shave several tenths of seconds from the total resume time.

Both need some amount of support in either the platform or in device drivers, and that's what I'm currently working on for the Tegra-based Chromebooks.
 

Related Posts

Related Posts

Comments (0)


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

syzkaller: fuzzing the kernel

26/03/2020

With the code base of the Linux kernel constantly changing and deployed in devices around the world, performing proper testing is crucial.…

Getting started with GStreamer's gst-build

19/03/2020

GStreamer relies on multiple repositories such as base and good to build its ecosystem, and now owns more than 30 projects in Gitlab. So,…

Why remote working can be good for people, business and environment

10/03/2020

Here at Collabora, we trust our people to work remotely, we give them full responsibility for their output, and we believe it helps creating…

PipeWire, the media service transforming the Linux multimedia landscape

05/03/2020

PipeWire 0.3 was released a few days ago, marking a big step forward in the effort of making this emerging media service the core layer…

Experimental Panfrost GLES 3.0 support has landed in Mesa

27/02/2020

Panfrost's ES 3.0 support has landed in upstream Mesa and works with a mainline Linux kernel. The support is still early, but if you're…

Using gcc sanitisers to get a nasty bug fixed

18/02/2020

When a bug surprises you when doing Apertis packaging of a typical vendor code signing tool, it's time to debug it using the compiler's…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2020. All rights reserved. Website sitemap.