LiveCDPerformance

Revision 31 as of 2005-11-02 21:34:46

Clear message

Live CD Performance

Introduction

The boot time for the Ubuntu live CD should be comparable (or superior) to other popular live CDs.

Rationale

The better the load time, the better the live CD experience, the greater chance an end user will want to use it and move on to installing Ubuntu or another distro.

Implementation Plan

  1. Instrumentation is required in order to identify bottlenecks. d-i logs stage 1, we can wrap init scripts to provide timing information on their startup. Bootchart would also be useful.
  2. Enable DMA on livecd - it may not work on some systems, but it's effectively required
  3. Optimise d-i modules that consume a large amount of time. Locale generation seems excessively slow, and potentially unnecessary for many language setups.

  4. Readahead may be a performance win with 256MB or more, but slower otherwise. Verify with different memory configurations, and ensure that readahead is only enabled when it's a performance benefit. http://unit.aist.go.jp/itri/knoppix/readahead/index-en.html has figures for Knoppix on cloop.

  5. Make sure modules.dep is generated at the end of the livecd build and call depmod --quick in the default boot.

  6. Filesystem comparison - squashfs and unionfs may give a performance benefit. http://listas.hispalinux.es/pipermail/metadistros-dev/2005-April/000580.html suggests a 50 second improvement.

  7. Background network setup - this can be left for when the user has hit the desktop (NetworkMagic)

Data Preservation and Migration

None.

Packages Affected

For instrumentation, init requires modification or bootchart, which will be a better choice. Performance issues in the first stage install will require d-i modifications. Any slow packages in second stage boot will need tweaks to improve performance.

User Interface Requirements

None.

Outstanding Issues

unionfs needs to be reintroduced into the kernel. See LiveCDUnionFS for more information.

Notes added after UDU Approval -PaulSladen:

  • Investigate cloop performance during boot:
    • Record actually-accessed files+blocks on the CD and whether these can be rearranged to avoid seek overhead
    • Selective reduction in zlib compression level for heavily accessed blocks if bootup turns out to be CPU-decompression bound, rather than I/O bound from the CD
      • Maybe possible to decompress files during boot at a small cost (eg. 20MB) on the CD image.
    • Memory overhead of double-cacheing (cdrom level, cloop level and uncompressed level)
      • Can pages that don't compress well be zero-compressed and direct-mapped.
        • This maybe possible at device-mapper level.
  • See also DLoop ideas
  • Looking at the Knoppix+readahead bootlogs above:
    • It is noticable that up until the 'curve', the non-readahead boot time is very consisent, regardless of memory. after the 'curve' the time varies massively from 1 minute and 5 minutes depending on how much memory is available.
    • The figures with readahead are slower on low-memory systems because:
      1. 30 seconds extra is spent just reading in data off disk
      2. this date is immediately tossed out again as memory is tight
    • The figures on high-memory systems are faster because:
      1. 30 seconds extra is spent just reading in data off disk
      2. after the 'curve', boot time is also instantanious because everything is in RAM.
    • Improvement can probably be made:
      1. Reducing initalisation time spent before the curve (this is consisent otherwise)
      2. Massively try to reduce files touched during X+GUI startup
      3. Move 'lots-of-files' applications to load before 'lots-of-RAM' applications as this will allow the RAM to be used for caching files, before being ditched and used for running applications. (RAM used by loaded applications *cannot* be 'ditched' as this is a Live environment which is unlikely to have swap-like facilities.

    • On the Knoppix bootcharts, over 45 seconds is spent on ddcxinfo-knoppix at 100% CPU

  • Compressed-swap-to-RAM facility to allow pages that would be paged out in tight-memory situations to be compressed and take less space. http://linuxcompressed.sourceforge.net/

  • Benchmark always using 1MB/2MB/5%/10% of RAM as swapram as Linux is actually weird and even providing a tiny amount of "swap" speeds up situations involving page-thrashing.

UDU BOF Agenda

  • d-i performance
  • casper performance

  • Ubuntu boot performance (FasterBoot)

UDU Pre-Work

  • Profile the live CD boot sequence to measure the time taken for each step
    • d-i startup (time-to-first-question)
    • Pre-casper d-i activity (measured per menu entry)
    • Casper d-i activity (measured per casper.d script)
    • Standard boot sequence

CategoryUdu CategorySpec