Jump to content

Bootup Time Things To Investigate

From eLinux.org

This page has a list of items which may be worth investigating.

Open questions that would be good to know the answers to

  • do you have to specify initcall_debug on the kernel command line in order to use initcall trace events?
  • do you have to specify initcall trace events on the kernel command line if you use initcall_debug?
  • if you defer jent_mod_init, does any boot-time cryptography or networking suffer (that is, is it made more vulnerable due to reduced random seeding of the RNG)?
  • is it possible for a program to modify bootconfig data without having to re-build the kernel?
  • is it possible to bypass handshakes with your router by using the ethtool command (or some other equivalent)?
  • what has the lowest overhead: initcall_debug or initcall trace events?
    • need to measure initcall_debug with 'quiet' on the kernel command line for a fair test
  • what is the overhead of initcall_debug and initcall trace events, and boot-time functional tracing?
    • which (if any) can be ignored for purposes of analyzing other delays?
  • can the cost of printks be calculated from a knowledge of the system speed and console type?
    • this would allow for factoring those out of the boot time calculations, without requiring a silent console at boot time
  • does the specific PHY hardware (IP block) have an effect on the time it takes for ethernet speed detection?
    • Doug Boom of "That Ethernet Company" seems to think so?
  • if so, which PHYs are the fastest to do the speed detection?
  • does the ethernet driver effect the time it takes for ethernet speed detection?
  • Are there ways to reduce handshake times for Wireless connections, or Bluetooth?

boot delays that need investigation

If you see something that creates a long delay (e.g. over 250ms) then add it here and maybe some day we will try to investigate it.

netconsole extra delay for bogus network carrier detect

Tim Bird saw this on the linux-tiny list: (see http://www.selenic.com/pipermail/linux-tiny/2004-August/000015.html)

Network devices that say they've got carrier detect instantly at boot are assumed to have bogus carrier detect and netconsole waits a bit to assure the line is up and ready to go before proceeding. The timeout mentioned below could probably be shrunk.

>eth0: NE2000 found at 0x300, using IRQ 5.
>> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
>> netconsole: device eth0 not up yet, forcing it
>> eth0: driver changed get_stats after register
>> netconsole: carrier detect appears flaky, waiting 10 seconds
>>                                            ^^^^^^^^---------this delay seems long