Intel Rapid Start support

Registered by Mario Limonciello on 2013-08-13

The firmware level feature of "Intel Rapid Start" ("iRST") works for Ubuntu as long as the appropriate partition is present and it's enabled in the firmware. Rapid Start will wake the machine up from S3, dump the contents of RAM to a special partition and put the system into S4. When the machine wakes up the firmware loads all the stuff from that partition back into RAM and returns to the OS. It's akin to a hybrid suspend+hibernate solution but has hardware level support but is more reliable and capable of being faster. Additionally, iRST hibernate works even if zram/compcache is used.

Some platforms are able to configure/enable settings for it in the firmware, while others are not. Kernel 3.11 is introducing a kernel module for modifying the settings for this, which is especially useful for platforms that can't modify this any other way other than from Windows.

The kernel module will only load if the firmware offers support for iRST, and the firmware will only offer iRST if:
* An SSD is present
* Ivy Bridge or newer/Intel 7 Series chipset support (very rare on Sandy Bridge/Intel 6 Series chipset, not present previously)
* Dedicated partition == to size of memory type 0x84 in MBR layout or GUID D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593 in GPT layout.
* BIOS support (would be exposed through ACPI if the above requirements are met)

There are a few places that could be expanded to make this experience better now starting with Kernel 3.11:
1) In the power management GUI, if the iRST module is loaded, offer to toggle the different settings the module adds a sysfs interface for. Turning on/off Rapid Start and configuring the timeout after suspend to kick in Rapid Start.

2) In the installer, the default automatic recipes should create this partition if possible, or at least offer a toggle for enabling. Currently, it should only kick in when 8GB or less RAM is present, the installation target is an SSD and it's an Intel Ivy Bridge chipset or newer. We should have a better method to determine whether a system supports iRST if at all possible.
 - This works for MBR or GPT, but the situation is tricky with MBR because of the limited number of possible partitions. For the installer, we might want to only offer the option of using iRST if installing in UEFI mode and using GPT.
 - We need a reliable way to detect this in advance of partitioning so that we're not spending 8GB extra disk for a partition that can't/won't be used
- Provide an installer hook to force enablement, so that OEMs can invoke that on the appropriate hardware.
- There's concern about reserving too much disk space for swap and hibernate. We would like to move to swap files regardless, but haven't done this yet for unrelated reasons.

3) If iRST is in use, default to a modified behavior for "hibernate" whereby, instead of using software hibernation, the OS instead sets the iRST timer to 0 and puts the computer to sleep.
 - For sleep, use a sensible timeout when firmware will write out RAM to SSD. This "sleep" will functionally be hybrid sleep. There is disagreement about whether a separate "hibernate" option should be exposed to the user, whereby "hibernate" is actually "let the firmware do iRST hibernate immediately after we put the system into S3".

4) What do we do differently if the user has an encrypted disk?
* what to do if encrypted swap is enabled - Section 2.6 of the Intel Rapid Start Technology Deployment Guide v1.0 (link below) covers how iRST handles different kinds of disk encryption. We can either disable iRST if software disk encryption is used or provide a way to flush and re-enter credentials on resume.
 * rapid start can be enabled *if* the disk is password protected, *or* homedir encryption (encrypted swap?) is not enabled.

5) What optimizations can be done in-OS to leverage iRST for faster hibernate/thaw?
Investigate the requirements within Linux for providing better reporting of "in-use" memory prior to sleep. Per Intel, "During the transition to the Sleep state, the service flushes the Standby and Modified memory pages to reduce the amount of memory reported as “in-use.” This can considerably reduce the amount of data that needs to be transferred to the SSD, resulting in improved resume time. Another function provided by the service is optimizing the amount of active pages that need to be written to the SSD. This feature is up to the OEM to enable. Similar to the above example, the service will flush the non-critical active pages during the Sleep transition. Again, this improves
resume performance but also reduces the required SSD partition size." <>

6) Newer implementations of iRST have optional support for hibernating to a partition that is smaller than the amount of memory in the system using an "Active Page Threshold" feature (per section 2.5.2 of the Intel Rapid Start Technology Deployment Guide).
 - How can we find out from the firmware that this is supported, and if it is, what is the threshold for a given system's configuration?

The Intel Rapid Start Technology Deployment Guide covers the technology's functionality:

Blueprint information

Not started
Jared Dominguez
Needs approval
Series goal:
Milestone target:

Related branches



Technology deployment guide:

"The Rapid Start Runtime Service in the operating system will discard Standby pages and flush Modified memory pages to the disk." - so yes we do want to flush caches before going to sleep.

"Intel recommends that this feature be enabled at the factory and the entry timer set to 60 minutes after entering S3 (Sleep)."

"Active Page Threshold Feature: If an OEM or system administrator wants to take advantage of a smaller partition they will need to enable the Active Page Threshold feature. Instead of comparing the partition size and DRAM at start up, this feature will perform a check during S3 entry. It compares the size of the active pages needing to be moved to the SSD to ensure there is enough space. If so, Intel Rapid Start Technology is enabled. If not, the system will remain in S3.
NOTES: this feature requires that the OEM enable support in BIOS. Check with the system OEM to ensure this feature is supported."

"Intel Rapid Start Technology is compatible with ATA security features (aka Drive Password), including self-encrypting drives (SEDs) that use the ATA Security feature set for locking/unlocking."

"Using Intel Rapid Start Technology with software-based full disk encryption is not recommended."

"the simplest setup is to create a partition equal to the maximum amount of DRAM that the system can hold."

page 17 - settings UI, on/off, critical battery on/off, timer slider.


If full disk software encryption, or home folder encryption is enabled (either at or post install time), rapid start should be disabled, as it will compromise data security and user privacy. (cryptsetup & ecryptfs)

Users are advised to keep the following option enabled "Require my password when waking from suspend" (check that it is default)

Above, should lock the screen before sleep and at the same time secrets' agents should drop caches. (gpg, ssh, gnome-keyring, secrets service API, KWallet, etc.)

What about external encrypted drives? might not be possible to unmount.

Should there be upstart events sys:syspend,resume, to potentially stop & start high-memory daemons (system-wide and/or user session)

On windows, there is a daemon that reduces active memory before going to suspend. Any background Metro-style apps receive suspend signal, and subsequently get killed. For example, Firefox writes out it's caches to disk & shuts down (yet able to resume / started with everything as before). Does converged unity help us here?

UI design for the power settings:

#possibly needs warnings when we disable sleep -> hibernate, due to encryption.


Work Items

Work items for ubuntu-13.08:
[cjwatson] add "is iRST present" option to partman-auto recipes, with best-effort detection and an override mechanism: TODO
[cjwatson] put optional iRST partition at the end of default GPT-based recipes: TODO
[jared-dominguez] follow up with BIOS folks to figure out what interfaces are provided for indicating which memory areas to write: INPROGRESS
[jared-dominguez] follow up with BIOS folks to find out more about Active Page Threshold feature: INPROGRESS
[xnox] discuss UI to enable/disable rapidstart, and notity/disable rapid start when security/privacy concerns arise (e.g. encrypted swap & ata passwords): INPROGRESS
[mpt] design "Power Settings" changes for iRST: DONE
design Installer UI changes to enable iRST (or auto-magic?!): TODO