FasterBootFromImage

Differences between revisions 1 and 11 (spanning 10 versions)
⇤ ← Revision 1 as of 2008-11-21 17:40:48 →
Size: 2529
Editor: nc-65-40-95-196
Comment:
← Revision 11 as of 2008-12-06 18:15:34 → ⇥
Size: 6222
Editor: 216
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''':
 * '''Packages affected''':		  * '''Contributors''': AmitKucheria
 * '''Packages affected''': grub, linux (kernel)
Line 9: Line 9:
TBD
Line 12: Line 11:
There are two ways to speed up system boot:
 1. Remove cruft from the boot sequence (parallelizing init scripts, readahead, removing modules, etc.)
 1. Bypass the boot sequence completely to boot into a pre-saved image

This spec talks about the second technique. The first one is already being addressed in other teams/sessions.
Line 13: Line 18:
Line 18: Line 22:
The x86 boot sequence is quite fragile with the multitude of (buggy) BIOSes that need to be supported. Hence the grub fast boot changes should not be the default option, but rather enabled explicitly by the user.
Line 19: Line 25:
Line 22: Line 27:
Netbook users and OEMs are asking for faster boot times so that the (mobile) devices are quickly usable. The idea is that these devices should have the response times of a traditional mobile device such as a mobile phone and the functionality of a laptop.
Line 23: Line 30:
 1. Alice is attending a conference. Typical of conferences, there are very few power sockets. While listening to the sessions, Alice would like to take notes, check email and then close the lid and go back to listening. She repeats this many times during the day. In order to save battery, the machine should suspend/hibernate when the lid is closed and resume ''quickly'' when it is opened. The battery should last the whole day on a single charge.
 1. Bob manages a server farm that guarantees 99.99% uptime. That means 52 minutes of downtime allowed per year. Considering some of these machines take 10+ minutes to boot, every second saved counts.
 1. Charlie manages a 1000-seat Linux desktop installation. A majority of his users do not power-off their computer at night because they want an instant-on experience in the morning. Some of the more conscientious users suspend the machine, but it still draws some power.

Alice needs her laptop to save power and become usable quickly. Suspend/Resume (STR) ought to give her that. If STR doesn't give a full days battery life, fast boot might become more attractive.

Bob could definitely use fast boot, but only if it supported his enterprise hardware configurations - so LVM and RAID support need to be thought about.

With Fast Boot, Charlie could mandate compulsory shutdowns since users would be more amenable to sub-30s boots.
Line 25: Line 41:
''Need to verify numbers from Intrepid''

Here are typical boot/suspend/hibernate/resume numbers from a laptop:

=== Shutdown numbers ===
 * Shutdown system: ~15s (why?!)
   * What happened to flush buffers to disk and kill power?
 * Hibernate: 20-50s
   * Freeing up memory and then saving the application state to disk takes time
 * Suspend: ~5s
   * Put memory in self-refresh and cut power to processor and board

=== Startup numbers ===
 * Fresh Boot: 60+ seconds
 * Resume from hibernate: ~40s (application state restored)
 * Fast boot: ~25s (from grub fast boot tests)
 * Resume from suspend: ~5s
Line 27: Line 60:
Line 31: Line 63:
Line 34: Line 65:
=== UI Changes === === Grub Fast Resume ===
 * patches from moblin.org
   * git://git.moblin.org/projects/grub.git
 * working swsusp
Line 36: Line 70:
##Should cover changes required to the UI, or specific UI that is required to implement this ==== Drawbacks ====
 * Grub patches against 0.9.7 which is a dead-end for upstream. So patches will never go upstream
   * Work reportedly ongoing to support Grub2
Line 38: Line 74:
=== Code Changes === === TuxOnIce ===
 * Resumes from disk a lot faster due to LZF compression
 * Nigel maintains a TuxOnIce kernel for all Ubuntu flavours (550Kb patch)
   * Git tree on kernel.ubuntu.com
 * Offer a .deb package to users?
Line 40: Line 80:
##Code changes should include an overview of what needs to change, and in some cases even the specific details. ==== Drawbacks ====
 * Work is not going upstream. EVER.
   * Upstream working at a kexec-based solution as successor to in-kernel suspend
Line 42: Line 84:
=== Migration ===

##Include:
## * data migration, if any
## * redirects from old URLs to new ones, if any
## * how users will be pointed to the new way of doing things, if necessary.		 === Snapshot boot for ARM ===
 * Proof-of-concept done on OSK5192 boards
 * Bootloader (u-boot) taught about swsusp image format
   * swsusp had to be ported to ARM first
Line 50: Line 90:
Line 63: Line 102:
 * How to enable grub fast boot optionally for users?
 * Can compression part of TuxOnIce be used with swsusp?

== Comments ==

 * The Launchpad page talks about TuxOnIce support. Is thissomething being seriously considered? I would loveto finally have it available. --MattPrice
   * The whole framework is quite big (500K patch). It would be nice if we could get some features of TuxOnIce ported to swsusp e.g. the LZF compression --AmitKucheria

Summary

There are two ways to speed up system boot:

  1. Remove cruft from the boot sequence (parallelizing init scripts, readahead, removing modules, etc.)
  2. Bypass the boot sequence completely to boot into a pre-saved image

This spec talks about the second technique. The first one is already being addressed in other teams/sessions.

Release Note

The x86 boot sequence is quite fragile with the multitude of (buggy) BIOSes that need to be supported. Hence the grub fast boot changes should not be the default option, but rather enabled explicitly by the user.

Rationale

Netbook users and OEMs are asking for faster boot times so that the (mobile) devices are quickly usable. The idea is that these devices should have the response times of a traditional mobile device such as a mobile phone and the functionality of a laptop.

Use Cases

  1. Alice is attending a conference. Typical of conferences, there are very few power sockets. While listening to the sessions, Alice would like to take notes, check email and then close the lid and go back to listening. She repeats this many times during the day. In order to save battery, the machine should suspend/hibernate when the lid is closed and resume quickly when it is opened. The battery should last the whole day on a single charge.

  2. Bob manages a server farm that guarantees 99.99% uptime. That means 52 minutes of downtime allowed per year. Considering some of these machines take 10+ minutes to boot, every second saved counts.
  3. Charlie manages a 1000-seat Linux desktop installation. A majority of his users do not power-off their computer at night because they want an instant-on experience in the morning. Some of the more conscientious users suspend the machine, but it still draws some power.

Alice needs her laptop to save power and become usable quickly. Suspend/Resume (STR) ought to give her that. If STR doesn't give a full days battery life, fast boot might become more attractive.

Bob could definitely use fast boot, but only if it supported his enterprise hardware configurations - so LVM and RAID support need to be thought about.

With Fast Boot, Charlie could mandate compulsory shutdowns since users would be more amenable to sub-30s boots.

Assumptions

Need to verify numbers from Intrepid

Here are typical boot/suspend/hibernate/resume numbers from a laptop:

Shutdown numbers

  • Shutdown system: ~15s (why?!)
    • What happened to flush buffers to disk and kill power?
  • Hibernate: 20-50s
    • Freeing up memory and then saving the application state to disk takes time
  • Suspend: ~5s
    • Put memory in self-refresh and cut power to processor and board

Startup numbers

  • Fresh Boot: 60+ seconds
  • Resume from hibernate: ~40s (application state restored)
  • Fast boot: ~25s (from grub fast boot tests)
  • Resume from suspend: ~5s

Design

Implementation

Grub Fast Resume

  • patches from moblin.org
    • git://git.moblin.org/projects/grub.git
  • working swsusp

Drawbacks

  • Grub patches against 0.9.7 which is a dead-end for upstream. So patches will never go upstream
    • Work reportedly ongoing to support Grub2

TuxOnIce

  • Resumes from disk a lot faster due to LZF compression

  • Nigel maintains a TuxOnIce kernel for all Ubuntu flavours (550Kb patch)

    • Git tree on kernel.ubuntu.com
  • Offer a .deb package to users?

Drawbacks

  • Work is not going upstream. EVER.
    • Upstream working at a kexec-based solution as successor to in-kernel suspend

Snapshot boot for ARM

  • Proof-of-concept done on OSK5192 boards
  • Bootloader (u-boot) taught about swsusp image format
    • swsusp had to be ported to ARM first

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

  • How to enable grub fast boot optionally for users?

  • Can compression part of TuxOnIce be used with swsusp?

Comments

  • The Launchpad page talks about TuxOnIce support. Is thissomething being seriously considered? I would loveto finally have it available. --MattPrice

    • The whole framework is quite big (500K patch). It would be nice if we could get some features of TuxOnIce ported to swsusp e.g. the LZF compression --AmitKucheria

CategorySpec

KernelTeam/Specs/FasterBootFromImage (last edited 2008-12-06 18:15:34 by 216)