From: eLinux.org

Filesystem Information

Boot Time with various file systems

Noboru Wakabayashi of Hitachi provided the following report.

On the OMAP Innovator he built the following file systems:

  • CRAMFS
  • CRAMFS with XIP
  • ROMFS
  • JFFS2
  • ext2 over RAM disk

He measured the time to initialize these file systems by logic analyzer.
This was done by modifying the busybox init program to make LED turn on
red. When innovator power on, the LED lights up green. So the time from
the light turning from green to red was measured. Also, he measured the
time using KFI (from start_kernel() to to_usrspace()).

Results are shown in the following table. (The result is average of 10
trials for each configuration.)









































Configuration/Filesystemlogic analyzer(sec)KFI(usec)
CRAMFS3.638850842789.1
CRAMFS with XIP2.788076764141.3
CRAMFS with XIP and PLPJ2.583988551735.5
ROMFS3.510876839078.2
JFFS24.8226421241068.4(log full)
ext2 over RAM diskcannot measure2952081.6(log full)
  • JFFS2: JFFS2 required much time at first boot time, so he measured
    from the 2nd starting.

  • CRAMFS: At first, he also measured the time with CONFIG_KFI by
    logic analyzer. The result is 4.324660 sec. It costs more than
    without CONFIG_KFI. So, he measured file systems without
    CONFIG_KFI when he used logic analyzer.

The attached zip file has the kfi logfiles for these different tests: no
zip found: kfi-results-omap-filesystems.zip

Next he remeasured the time to initialize “CRAMFS with XIP and PLPJ”
using the “quiet” option. The result is 280676 usec from start_kernel()
to to_userspace(). The above result is 551735.5 usec.The time is
reduced about 50%.

The following table shows output from ‘kd’ on the kfi logfile.


























































































































































































































































output from ‘kd’ on the kfi logfile
FunctionCountTimeAverageLocalMax-subMs count
do_basic_setup1114068114068509do_initcalls1
mem_init1110376110376490free_all_bootmem_node1
free_all_bootmem_node110937810937812free_all_bootmem_core1
free_all_bootmem_core1109366109366109366-0
schedule1084482844834do_schedule10
do_schedule10844488444574switch_to9
do_initcalls184159841593831device_init1
switch_to983874931983874-0
register_proc_table2239161178013079register_proc_table18
device_register11222972027415device_add11
device_add112188219891439kobject_add11
device_init1206332063330net_dev_init1
tifb_init11875918759844register_framebuffer1
register_framebuffer1130921309288take_over_console1
take_over_console11300413004819redraw_screen1
kobject_add1512996866738create_dir15
setup_arch11254212542131paging_init1
paging_init11241112411386free_area_init_node1
create_dir15122588173625populate_dir9
free_area_init_node1120251202530free_area_init_core1
free_area_init_core111995119957496__alloc_bootmem_node1
rs_init11179411794377printk3
inet_init111696116961718ip_init1
redraw_screen2112475623871do_update_region1
printk181087060310870-0
net_dev_init110334103343102ethif_probe1

Probe times for various file systems

As part of work supported by Sony/Matsushita, Todd Poynor got the
following numbers using KFI on a 200MHz IBM 405GP “Walnut” evaluation
board with a 100MHz core bus and 33MHz PCI bus. A Seagate Barracuda ATA
IV 60GB disk drive is cabled to one of the two IDE interfaces on a
Promise Ultra66 PCI-IDE bridge card (PDC20262 chipset). All of the
drivers for PCI, IDE, PCI-IDE disk, and EXT2 filesystem are built into
the kernel.

Boot execution time of IDE/PCI-IDE/MS-DOS partition drivers: 262 msecs.
This includes the time to probe and identify the IDE drive device and
read the disk partition information from the drive. We booted the kernel
with option hdf=none to turn off the slave device on interface ide2, so
that it would not be probed. We also modified the kernel to turn off
probes of the second IDE interface on the Promise card. (This was prior
to fixing the “ide\=noprobe” option bug. If you don’t turn off
probing the second empty IDE interface then probling takes 1.3 seconds
on both a PPC 405GP and a MIPS ITE8172!)

About 250 msecs of the time is spent during the bus probe in repeated
calls to ide_delay_50ms() during probe and drive identification, which
busywaits (in order to let the IDE controller make progress before
polling for status or to allow previous operations to complete). Reading
capacity info, etc. also blocks using a wait_for_completion(). The
MSDOS partition code also locks pages, which can call schedule() to wait
for locks.

If the IDE drivers are made modules for delayed initialization, allowing
concurrent module initialization with application execution, then kernel
preemption is turned off for about 252 msecs during init of the
ide-probe-mod module, which could significantly interfere with real-time
response of other threads. (This was verified using the
CONFIG_PREEMPT_TIMES feature that gives preemption lock times in
/proc/latencytimes, which is also supported in the CELF kernel.) Because
the Big Kernel Lock (BKL) is held during module initialization,
preemption is disabled while the module init routines runs and uses
busywait calls, but preemption is allowed when CPU-yielding wait calls
are employed (the linux scheduler drops and reacquires the BKL in this
case).

So we changed the ide_delay_50ms() busywaits to call
schedule_timeout() instead (this is also in the CELF kernel; select
CONFIG_IDE_PREEMPT), resulting in a 9.68 msec maximum preempt off
time. Note that if you’re not using modules but are instead building the
drivers statically into the kernel, then the CPU-yielding calls do add
some amount of time to the total execution time due to context-switch
overhead, etc.

My coworker Dave Singleton also did some analysis and improvement of IDE
on the MIPS ITE8172 (again for Sony/Matsushita). He found that with his
7200RPM Maxtor drive, he could reduce the 50ms probe delays to 1ms with
no problem. With this, plus some context switch removal and the other
optimizations given above, the following boot times were observed, by
filesystem type:

{{{ ext2: 167 milliseconds ext3: 457 milliseconds xfs: 236 milliseconds
}}}

He explains: “Both EXT3 and XFS file systems cause a log replay at
boot/mount time. To improve this time the log recovery feature was by
passed in the case of XFS. The log was not replayed and the root file
system was mounted readonly. The first init script after booting
remounted the root file system readwrite and replayed the log to ensure
file system integrity. No such changes were made to EXT3, which is the
reason it had the slowest boot times of all 3 file system types.”

Category: