Difference between revisions of "Improving Android Boot Time Outline"

From eLinux.org
Jump to: navigation, search
(Created page with 'Here is the outline for my talk: * Title * Outline ** Android boot overview ** Measuring boot times ** Problem areas *** Some gory details ** Ideas for improvements * Android boo…')
 
(add rules between slides)
Line 1: Line 1:
 
Here is the outline for my talk:
 
Here is the outline for my talk:
 
* Title
 
* Title
 +
----
 
* Outline
 
* Outline
 
** Android boot overview
 
** Android boot overview
Line 7: Line 8:
 
*** Some gory details
 
*** Some gory details
 
** Ideas for improvements
 
** Ideas for improvements
 +
----
 
* Android boot overview
 
* Android boot overview
 
** bootloader
 
** bootloader
Line 16: Line 18:
 
** service manager
 
** service manager
 
*** start services
 
*** start services
 +
----
 
* measuring bootup time
 
* measuring bootup time
 
** systems measured: adp1, n1, evm
 
** systems measured: adp1, n1, evm
Line 22: Line 25:
 
*** evm with eclair
 
*** evm with eclair
 
**** NOTE: used nfs root filesystem (file IO timings might be bogus)
 
**** NOTE: used nfs root filesystem (file IO timings might be bogus)
 +
----
 
* Tools for measuring and tracing boot time
 
* Tools for measuring and tracing boot time
 
** stopwatch
 
** stopwatch
Line 31: Line 35:
 
** method tracer*
 
** method tracer*
 
** ftrace*
 
** ftrace*
 +
----
 
* stopwatch
 
* stopwatch
 +
----
 
* grabserial
 
* grabserial
 +
----
 
* printk times
 
* printk times
 +
----
 
* bootchart
 
* bootchart
 +
----
 
* strace
 
* strace
 +
----
 
* logcat
 
* logcat
 
** extra instrumentation for preloading classes
 
** extra instrumentation for preloading classes
 
** PARSE_CHATTY flag for package scanning
 
** PARSE_CHATTY flag for package scanning
 
** mention my own tool 'logdelta'
 
** mention my own tool 'logdelta'
 +
----
 
* method tracer*
 
* method tracer*
 
** method traces is built in to  
 
** method traces is built in to  
−
** ftrace?? (no)
+
* 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
 
* Problem Areas
 
** First, a bootchart for EVM board
 
** First, a bootchart for EVM board
Line 50: Line 67:
 
** package scanning
 
** package scanning
 
** service initialization
 
** service initialization
 +
----
 
* bootloader init
 
* bootloader init
 
** outside scope of this talk
 
** outside scope of this talk
 
** didn't measure commercial bootloader, only development one (U-boot)
 
** didn't measure commercial bootloader, only development one (U-boot)
 +
----
 
* kernel init
 
* kernel init
 
** is mostly the usual suspects
 
** is mostly the usual suspects
 
** (initcall_debug results)
 
** (initcall_debug results)
 
** USB
 
** USB
 +
----
 
* zygote class preloading
 
* zygote class preloading
 
** zygote pre-loads just under 2000 classes, and instantiates them in its heap
 
** zygote pre-loads just under 2000 classes, and instantiates them in its heap
 
** controlled by file:
 
** controlled by file:
 +
----
 
* package manager package scan
 
* package manager package scan
 
** exact purpose is not known
 
** exact purpose is not known
 
*** validation of certificates, permissions, capabilities and dependencies, etc.?
 
*** validation of certificates, permissions, capabilities and dependencies, etc.?
 
** EVERY package is scanned at boot time
 
** EVERY package is scanned at boot time
 +
----
 
* ideas for enhancements
 
* ideas for enhancements
 
** kernel speedups
 
** kernel speedups
Line 70: Line 92:
 
** miscellaneous optimizations
 
** miscellaneous optimizations
 
** sreadahead??
 
** sreadahead??
 +
----
 
* kernel speedups
 
* kernel speedups
 
** outside the scope of this presentation
 
** outside the scope of this presentation
 
** see http://elinux.org/Boot_Time
 
** see http://elinux.org/Boot_Time
−
* optimize package scan
+
** should really be able to get kernel up in 1 second
−
*** most definitely
+
*** modulo network delays
−
*** need to continue analysis
+
----
−
**** most likely, should switch to a compressed flash file system
+
* Optimize Class Preloading
−
** use pre-constructed dalvik heap? (difficult?)
+
** Preload less, and let apps pay penalty for shared class and resource use
−
*** thread the heap construction?
+
*** move some classes to services, and have preload be a thin stub
−
* sreadahead??
+
*** 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
 
** could use sreadahead to pre-fill page cache
 
** however, this just masks bad behavior
 
** however, this just masks bad behavior
Line 86: Line 142:
 
**** better to just optimize or eliminate parseZipArchive()
 
**** better to just optimize or eliminate parseZipArchive()
 
** sreadahead should be used dead last (after all other enhancements)
 
** sreadahead should be used dead last (after all other enhancements)
−
 
+
----
−
      - don't know how to preconstruct heap
+
* Conclusions
−
      - need to analyze heap
+
** Sorry - no speedups yet
−
        - FIXTHIS - is heap identical on every boot?
+
** firm foundation for improving things going forward
−
          - how to dump heap memory
+
----
−
          - how to dump any memory in Android??
+
* Observations
−
        - are parts identical??
+
−
    - zoneinfo inefficiencies
+
−
        - measure without strace, and see if time is a problem
+
−
  - remaining questions
+
−
    - future directions
+

Revision as of 17:48, 28 July 2010

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
Retrieved from "http://elinux.org/index.php?title=Improving_Android_Boot_Time_Outline&oldid=22544"