MobileCasperSpeedup

Summary

Investigate whether it is possible to clean-up and speed-up the casper boot process to improve the live-cd experience.

Please see ARM/CasperSpeedup for a look at progress on this spec.

Release Note

Casper is a hook for initramfs-tools used to generate an initramfs capable to boot live systems as those created by make-live. At boot time it will look for a (read-only) media containing a "/casper" directory where a root filesystems (often a compressed squashfs) is stored. If found, it will create a writable environment, using unionfs, for debian like systems to boot from.

Especially on ARM, and one could argue in general, Casper can make the live-cd session seem very slow to boot. This process will be looked at to ensure that there is no unnecessary time-wasting, sub-optimal and unneeded code.

Rationale

Casper can be very slow on ARM which give a bad impression on boot-up. It has been put together over time and could contain some un-optimized scripts which could be improved to improve the users experience of the live-cd.

User stories

  • Bob is booting his new ARM based hardware with a fresh image on a USB stick. He has to wait a full 5 minutes for the desktop to appear. Bob impression of the Ubuntu experience isn't optimal.

Assumptions

  • Casper can be improved.
  • There is some process that takes longer on ARM than on i386 due to ARM's hardware.

Design

  • A mechanism is needed to find out exactly where the time is being spent in Casper. This can be a simple time logging statement or something more fancy.
  • If this is to be used on other architectures and maybe in more general terms, a more professional solution has to be produced.
  • Integration with bootchart may be an option. If this is the case then bootchart will need to be promoted from universe.
  • If we use bootchart we could also profile ubiquity which is another cause of slowdown on ARM installs.
  • oprofile could be used to profile ubiquity.

Implementation

UI Changes

Should have no visual effect for the user apart from an increase in boot speed.

Code Changes

  • Possible code changes to Casper scripts and any packages that investigations discover to be improvable.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

BoF agenda and discussion

Notes from UDS session.

Action Points

  • Need to measure current casper process.
    • Time stamps in casper.log.
    • bootchart.
      • java chart generation would have to be done on a non-ARM machine.
    • bootchart as a default install.
    • NCommander to talk to Colin about promoting bootchart (or enabling universe).
      • All dependances are in main already.

    • JamieBennett to shadow NCommander for main promotion and custom image building.

    • Use ubiquity with oprofile to profile applications.
    • Run ubiquity with bootchart.

Notes

  • Tool to boot live images.
  • iMX51 shows that casper is extremely slow on ARM hardware.
    • Same behavior also seem on Dove
  • Hooks into initramfs to set up all the live session.
  • Generating locales and keymaps are slow.
  • xmodmap could contribute to the slowness on ARM.
  • Scanning for devices could be an issue.
  • Could explictly specify the boot device and remove probing.
  • bootchart is in universe.
    • promote it or enable universe?

CategorySpec

Specs/MobileCasperSpeedup (last edited 2010-01-04 13:11:56 by 5ad01be5)