Improving Android Boot Time Outline

From eLinux.org
Revision as of 17:48, 28 July 2010 by Tim Bird (Talk | contribs)

Jump to: navigation, search

Here is the outline for my talk:

  • Title

  • Outline
    • Android boot overview
    • Measuring boot times
    • Problem areas
      • Some gory details
    • Ideas for improvements

  • Android boot overview
    • bootloader
    • kernel
    • init
    • zygote
      • building preload heap
      • start package manager
    • service manager
      • start services

  • measuring bootup time
    • systems measured: adp1, n1, evm
      • adp1 with donut
      • n1 with eclair
      • evm with eclair
        • NOTE: used nfs root filesystem (file IO timings might be bogus)

  • Tools for measuring and tracing boot time
    • stopwatch
    • grabserial
    • printk times
    • bootchart
    • strace
    • logcat
    • method tracer*
    • ftrace*

  • stopwatch

  • grabserial

  • printk times

  • bootchart

  • strace

  • logcat
    • extra instrumentation for preloading classes
    • PARSE_CHATTY flag for package scanning
    • mention my own tool 'logdelta'

  • method tracer*
    • method traces is built in to
  • ftrace*
    • I could have really used ftrace for some things
    • (especially to see page faults intermingled with system calls)
    • kernel version for my primary development board (2.6.29) didn't support it
    • should be usable in future versions of Android (Froyo is at 2.6.32)
    • NOTE: ARM is missing function graph tracing - see Ftrace Function Graph ARM

  • Problem Areas
    • First, a bootchart for EVM board
    • bootloader init
    • kernel init
    • zygote class preloading
    • package scanning
    • service initialization

  • bootloader init
    • outside scope of this talk
    • didn't measure commercial bootloader, only development one (U-boot)

  • kernel init
    • is mostly the usual suspects
    • (initcall_debug results)
    • USB

  • zygote class preloading
    • zygote pre-loads just under 2000 classes, and instantiates them in its heap
    • controlled by file:

  • package manager package scan
    • exact purpose is not known
      • validation of certificates, permissions, capabilities and dependencies, etc.?
    • EVERY package is scanned at boot time

  • ideas for enhancements
    • kernel speedups
    • optimize package scan
    • optimize class preloading
    • miscellaneous optimizations
    • sreadahead??

  • kernel speedups
    • outside the scope of this presentation
    • see http://elinux.org/Boot_Time
    • should really be able to get kernel up in 1 second
      • modulo network delays

  • Optimize Class Preloading
    • Preload less, and let apps pay penalty for shared class and resource use
      • move some classes to services, and have preload be a thin stub
      • figure out how to share heap back with zygote
    • Thread the heap construction
      • There is some evidence that class preloading has I/O waits, and would benefit from threading
      • Don't know if this is possible
      • NOTE: all threads need to terminate before spawning Android apps
    • Use pre-constructed dalvik heap
      • (more on next slide)

  • Use pre-constructed dalvik heap
    • Basic operation:
      • Snapshot the heap at end of preloading
      • Check for modifications to any class in preload list, and do regular preload
      • Otherwise, load pre-constructed heap
    • Issues:
      • Don't know if this is possible
        • Need to find parts of heap that are identical on each boot
        • Probably need separate "always-the-same" and "may-change" classes
      • Needs careful analysis, and knowledge of each class

  • Optimize Package Scan
    • Most definitely! should be first thing attacked
    • Need to continue analysis
      • Most likely, should switch to a compressed flash file system

  • Miscellaneous
    • zoneinfo inefficiences
      • discovered with strace
      • routines that do read syscall for 40 bytes, 8 bytes, 8 bytes (hundreds of times)
        • no buffering at user level, sloppy loop coding
      • linear scan of timezone file
        • for a file not present!!
      • probably only a few hundred milliseconds, but worth changing

  • Sreadahead??
    • could use sreadahead to pre-fill page cache
    • however, this just masks bad behavior
      • Contacts.apk (half of 1.6M) is read 4 times! during boot
      • filling page cache makes reads after first one fast, but it would be better to avoid all these reads altogether
        • better to just optimize or eliminate parseZipArchive()
    • sreadahead should be used dead last (after all other enhancements)

  • Conclusions
    • Sorry - no speedups yet
    • firm foundation for improving things going forward

  • Observations