Difference between revisions of "Android Boot-time Readahead"

From eLinux.org
Jump to: navigation, search
(create page to support my ABS presentation)
 
(Testing boot speed on Android)
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Here is information about Android Boot-Time Readahead
 
Here is information about Android Boot-Time Readahead
  
''to do: need to post my programs, with source, my presentation from ABS, and some of my raw results''
+
== Presentation ==
 +
This is the presentation I gave at ABS 2011.
  
 +
[[Media:abs2011_bird_readahead.pdf|abs2011_bird_readahead.pdf]]
 +
 +
== Results ==
 +
Bottom line results were an approximate 5% (1.5 seconds) improvement in boot
 +
time, using readahead on only a single portion of the boot sequence.  A 9%
 +
improvement was expected, given the area of the boot sequence that was
 +
optimized.  So, it didn't help as much as I'd hoped, but did help a little.
 +
 +
More testing is needed:
 +
* to determine why adjusting the I/O scheduling priority did not have the expected affect
 +
* to apply readahead to more part of the boot sequence
 +
* to test other methods to avoid interfering with foreground processing
 +
** like, manually halting and continuing readahead during the boot, and performing smaller reads
  
 
== Programs ==
 
== Programs ==
 +
These are test programs, but there's nothing in them that prevents them
 +
from being used for actual systems.  readahead does not intrinsically alter
 +
any functionality on the system.  It only changes the contents of the page
 +
cache.  Worst case behavior ''should be'' that things boot a bit slower. Best
 +
case behavior is that boot time improves a lot.  Please measure with
 +
bootchart and let me know how it goes.
 +
 
=== mincore ===
 
=== mincore ===
 
Mincore is a program I wrote to report the pages in the Linux page cache for requested files.
 
Mincore is a program I wrote to report the pages in the Linux page cache for requested files.
 +
 +
Here's the source:
 +
 +
[[Media:mincore.c]]
  
 
=== logsync ===
 
=== logsync ===
 
Logsync is a program to write a log message to both the kernel log buffer (printk), and the Android log buffer.  On most systems, the timestamps are different between these two logging systems.
 
Logsync is a program to write a log message to both the kernel log buffer (printk), and the Android log buffer.  On most systems, the timestamps are different between these two logging systems.
 
This is useful to determine a unified ordering of events reported by these separate systems.
 
This is useful to determine a unified ordering of events reported by these separate systems.
 +
 +
[[Media:logsync.c]]
  
 
=== treadahead ===
 
=== treadahead ===
Line 16: Line 43:
 
facilities for recording iowait before and after a readahead sequence, timing the duration of
 
facilities for recording iowait before and after a readahead sequence, timing the duration of
 
readahead operations, and changing things like the process scheduling priority, I/O scheduler, and I/O scheduling priority.
 
readahead operations, and changing things like the process scheduling priority, I/O scheduler, and I/O scheduling priority.
 +
 +
[[Media:treadahead-1.3.tgz]]
 +
 +
You can build this in context of the Android build system (using the included Android.mk) or using
 +
a regular Linux host compiler (using the included Makefile).  Note that this would build for a 32-bit x86 system (which is what the Sony Internet TV is).
 +
 +
The source includes readahead.S, which is assembly for adding a wrapper for the readahead syscall on ARM systems.
 +
Bionic on ARM is missing the wrapper for the readahead syscall.
 +
 +
== How to use Treadahead ==
 +
 +
=== programs ===
 +
mincore is used to gather information about the blocks of a file that are
 +
in memory.  You hand it a file list, and it outputs a list of blocks.  Use
 +
the -r options to specify that the output should be in treadahead format.
 +
 +
treadahead is used to read files and parts of files into memory.  You
 +
can specify the areas to read on the command line or in the file
 +
/readahead_list.txt
 +
 +
Each line in the readahead_list.txt file specifies a file to read, with
 +
syntax:
 +
  <filename>[ area_list]
 +
 +
  area_list is: <offset>:<len>[,<offset>:<len>]
 +
 +
If the area_list is empty, then the whole file is read ahead.
 +
 +
Here is an example:
 +
/system/framework/framework-res.apk
 +
/system/app/Contacts.apk 0:4096,1282048:4096,1294336:4096,1470464:12288
 +
 +
This would read everything in framework-res.apk, and only certain portions of Contacts.apk
 +
 +
To build the needed data file, you need to follow these steps:
 +
* build a list of files to scan
 +
* use mincore with the list of files, to build a list of blocks to readahead
 +
* use treadahead in /init.rc to readahead the blocks
 +
 +
For testing, you may wish to remove blocks from the kernel page cache.
 +
You can do this with:
 +
$ echo 1 >/proc/sys/vm/drop_caches
 +
 +
You can echo either '1', '2', or '3' to drop_caches.
 +
'1' drops pagecache, '2' drops dentries and inodes, and '3' drops both)
 +
 +
In sreadahead, the list of files is determined by examining trace data
 +
for file opens during the boot.
 +
For my early testing of treadahead, I used files that I found were consuming
 +
a lot of load time, from instrumenting the zygote process during its
 +
class preloading time (and also the package scanning during the application
 +
manager initialization)
 +
 +
=== Actual Usage ===
 +
To build a list of files (for /readahead_files.txt), boot the system,
 +
then soon after system start do:
 +
# find . -name "*.apk" | xargs mincore
 +
 +
Put the names of files with significant blocks in cache, into
 +
        /readahead_files.txt
 +
 +
To create the block list reboot again and do:
 +
# cat /readahead_files.txt | xargs mincore -r >/readahead_list.txt
 +
 +
To start the system with readahead turned on, add these lines to /init.rc
 +
 +
service treadahead /system/bin/treadahead -e -f
 +
        oneshot
 +
 +
The '-e' puts treadahead in the background and the '-f' tells treadahead to
 +
read the list of files and blocks from the file /readahead_files.txt.
 +
 +
=== Testing boot speed on Android ===
 +
To see the boot speed (and impact of readahead), read the 'events' log
 +
and the 'main' log.
 +
 +
Grab the event log with:
 +
$ adb logcat -b events -d >eventlog1.txt
 +
Grab the main log with:
 +
$ adb logcat -d >mainlog1.txt
 +
 +
Find the class preload timestamps with:
 +
$ grep boot eventlog1.txt
 +
Find the total start time with:
 +
$ grep enable_screen eventlog1.txt
 +
 +
Find the class preload durations with:
 +
$ grep preloaded mainlog1.txt
 +
Find the time to scan packages with:
 +
$ grep Time mainlog1.txt
 +
 +
You can compare results from different runs by grepping with shell wildcards:
 +
$ grep enable_screen *
 +
or
 +
$ grep Time *
 +
 +
=== Related material ===
 +
See the presentation: [[Media: Android-bootup-time-celf-jamboree34.ppt]]
 +
 +
This has results for using 'cat <foo> >/dev/null' in init.rc, which improved
 +
boot time on the EVM board, which used an NFS root filesystem.
 +
 +
[[Category:Android]]
 +
[[Category:Boot Time]]
 +
[[Category:Presentations]]

Latest revision as of 15:07, 22 January 2013

Here is information about Android Boot-Time Readahead

Presentation

This is the presentation I gave at ABS 2011.

abs2011_bird_readahead.pdf

Results

Bottom line results were an approximate 5% (1.5 seconds) improvement in boot time, using readahead on only a single portion of the boot sequence. A 9% improvement was expected, given the area of the boot sequence that was optimized. So, it didn't help as much as I'd hoped, but did help a little.

More testing is needed:

  • to determine why adjusting the I/O scheduling priority did not have the expected affect
  • to apply readahead to more part of the boot sequence
  • to test other methods to avoid interfering with foreground processing
    • like, manually halting and continuing readahead during the boot, and performing smaller reads

Programs

These are test programs, but there's nothing in them that prevents them from being used for actual systems. readahead does not intrinsically alter any functionality on the system. It only changes the contents of the page cache. Worst case behavior should be that things boot a bit slower. Best case behavior is that boot time improves a lot. Please measure with bootchart and let me know how it goes.

mincore

Mincore is a program I wrote to report the pages in the Linux page cache for requested files.

Here's the source:

Media:mincore.c

logsync

Logsync is a program to write a log message to both the kernel log buffer (printk), and the Android log buffer. On most systems, the timestamps are different between these two logging systems. This is useful to determine a unified ordering of events reported by these separate systems.

Media:logsync.c

treadahead

Tim's readahead - This is a test program to experiment with various readahead options. Besides actually performing readahead operations, it includes facilities for recording iowait before and after a readahead sequence, timing the duration of readahead operations, and changing things like the process scheduling priority, I/O scheduler, and I/O scheduling priority.

Media:treadahead-1.3.tgz

You can build this in context of the Android build system (using the included Android.mk) or using a regular Linux host compiler (using the included Makefile). Note that this would build for a 32-bit x86 system (which is what the Sony Internet TV is).

The source includes readahead.S, which is assembly for adding a wrapper for the readahead syscall on ARM systems. Bionic on ARM is missing the wrapper for the readahead syscall.

How to use Treadahead

programs

mincore is used to gather information about the blocks of a file that are in memory. You hand it a file list, and it outputs a list of blocks. Use the -r options to specify that the output should be in treadahead format.

treadahead is used to read files and parts of files into memory. You can specify the areas to read on the command line or in the file /readahead_list.txt

Each line in the readahead_list.txt file specifies a file to read, with syntax:

 <filename>[ area_list]
 area_list is: <offset>:<len>[,<offset>:<len>]

If the area_list is empty, then the whole file is read ahead.

Here is an example:

/system/framework/framework-res.apk
/system/app/Contacts.apk 0:4096,1282048:4096,1294336:4096,1470464:12288

This would read everything in framework-res.apk, and only certain portions of Contacts.apk

To build the needed data file, you need to follow these steps:

  • build a list of files to scan
  • use mincore with the list of files, to build a list of blocks to readahead
  • use treadahead in /init.rc to readahead the blocks

For testing, you may wish to remove blocks from the kernel page cache. You can do this with:

$ echo 1 >/proc/sys/vm/drop_caches

You can echo either '1', '2', or '3' to drop_caches. '1' drops pagecache, '2' drops dentries and inodes, and '3' drops both)

In sreadahead, the list of files is determined by examining trace data for file opens during the boot. For my early testing of treadahead, I used files that I found were consuming a lot of load time, from instrumenting the zygote process during its class preloading time (and also the package scanning during the application manager initialization)

Actual Usage

To build a list of files (for /readahead_files.txt), boot the system, then soon after system start do:

# find . -name "*.apk" | xargs mincore

Put the names of files with significant blocks in cache, into

       /readahead_files.txt

To create the block list reboot again and do:

# cat /readahead_files.txt | xargs mincore -r >/readahead_list.txt

To start the system with readahead turned on, add these lines to /init.rc

service treadahead /system/bin/treadahead -e -f
       oneshot

The '-e' puts treadahead in the background and the '-f' tells treadahead to read the list of files and blocks from the file /readahead_files.txt.

Testing boot speed on Android

To see the boot speed (and impact of readahead), read the 'events' log and the 'main' log.

Grab the event log with:

$ adb logcat -b events -d >eventlog1.txt

Grab the main log with:

$ adb logcat -d >mainlog1.txt

Find the class preload timestamps with:

$ grep boot eventlog1.txt

Find the total start time with:

$ grep enable_screen eventlog1.txt

Find the class preload durations with:

$ grep preloaded mainlog1.txt

Find the time to scan packages with:

$ grep Time mainlog1.txt

You can compare results from different runs by grepping with shell wildcards:

$ grep enable_screen *

or

$ grep Time *

Related material

See the presentation: Media: Android-bootup-time-celf-jamboree34.ppt

This has results for using 'cat <foo> >/dev/null' in init.rc, which improved boot time on the EVM board, which used an NFS root filesystem.