Firefox OS/Performance/Boot Sequence Optimization
Initial Ideas
- Minimize data loaded by boot loader.
- Compacting vmlinuz/zImage by moving compiled-in drivers to modules.
- Minimize initial ramdisk if there is one.
- Minimize kernel cruft by excluding all unneeded drivers.
- Strip the kernel and all modules.
- Minimize init launch sequence.
- Make init only launch the bare minimum for b2g process to launch.
- Ideally, init will only launch b2g.
- B2G start-up sequence.
- Remove all synchronous external dependencies from B2G start-up sequence.
- Kernel modules must be lazy loaded as needed.
- Any sync waits on daemons must become async. Start-up b2g pieces as daemons finish launching.
- Minimize start-up initializations.
- Global statics need to be minimized as their constructors are run before main().
- Global singletons must be initialized as needed.
- Remove all synchronous external dependencies from B2G start-up sequence.
- Homescreen start-up.
- Minimize _init() code to bare minimum.
- Maybe freeze the homescreen app into a memory image that can be loaded and unfrozen instead of launching the app every time.
- Eliminate dependency on enumerating installed apps on launch.
- Cache the list in local storage?
- Cache the list in the frozen memory image?
- Speed up mgmt.getAll()
The Plan
Bootchart
Some example preliminary data collected via bootchart here.
To enable the collection of bootchart data in FireFox OS one must build init with the following environment variable set.
INIT_BOOTCHART=true
Once init has been replaced on the device (see process here), to enable logging one simply creates a file |/data/bootchart-start| on the device containing an integer representing the number of seconds for which bootchart should collect data, and then reboot the device.
Bootchart data is pulled from the device with the system/core/grab-bootchart.sh script, and presented in the form of a bootchart.tgz file. With the data collected one can then generate graphs by invoking:
java -jar bootchart.jar -f eps bootchart.tgz
Without the |-f eps| parameters, the default is for a PNG to be generated. The SVG format is also supported.
Notice that the charts generated by the stock bootchart.jar do not seem to include disk stats. This is because it does not recognize the mmcblkNpM format of partition namea, and this can easily be fixed in the bootchart source code ( in particular, at |bootchart-0.9/src/org/bootchart/parser/linux/ProcDiskStatParser.java| ).
Data
These are some stats collected for the purposes of establishing a baseline. Things are organized as follows:
repo-state -> Information about the state of the source tree that applies to this experiment.
Note that things such as changes in init.rc, kernel arguments would not be visible in this
N/ -> Each of the numbered directories represent one sample of data
N/bootchart.N.tgz -> Bootchart archive encapsulating the data that was collected
N/kmsg.N -> A dump of the kernel logs of the device
Contains timestamp for when init has started, and time stamp for when b2g.sh is run by init
(and misc. other component initialization)
N/logcat.N -> A dump of the android logs of the device
Contains timestamp of when b2g has started (which is also useful to synchronize with kernel log times)
(since logcat logs time absolutely, and kmsg as an offset from startup
N/rebootstamp.N -> Local unix time recorded directly after an adb reboot to approximate time of boot
N/synchstamp.N -> Kernel logs are time since boot and so are the process start times, this file contains the local time and the current device
uptime so that one may determine when the kernel logs were initialized
For this and future data collection, at least 30 trials will be recorded. Also in the root directory there are a few randomly selected trials for which charts were generated for quick reference.
A rough idea of what we are seeing currently, as well as empirical hypotheses: