[clue-tech] localyesconfig

June Tate-Gans june at theonelab.com
Fri Feb 5 08:26:05 MST 2010


On 2/4/10, Jason Ash <wizardofki at gmail.com> wrote:
> Back when I was trying LFS, there was a time command to wrap other
> commands in to see how much time compiling, etc., took, but I never
> figured out how to get it to work. Therefore, to really gain a metric
> for how fast it boots, I'd either have to learn how to use the time
> command in conjunction with booting, some other time tracking
> command/script, or use a stop watch, the later of which would still be
> error prone.

time(1) is a standard *NIX command. To use it, just do this:

   $ time $COMMAND

Where $COMMAND is any command you wish to time. It's pretty simple,
time just grabs the args you give it, forks, runs the args through a
shell and times how long it takes for the child process to quit.

Unfortunately, this is near useless for the initial boot of a system.
Instead, the Fedora guys put together a system to time the boot
sequence from the start of the sysvinit scripts called bootchart. It's
built into Gentoo as well -- just edit /etc/conf.d/rc and change
RC_BOOTCHART to "yes". Once that's done, you'll need to emerge
app-benchmarks/bootchart to actually start generating charts with
timing information in them. There's a bit of information on it at
<http://www.bootchart.org>, though I imagine there's probably some
more Gentoo-specific information on the Gentoo wiki.

There's a trick here, though: bootchart does take up some decent
amount of disk space (especially if you do this on a desktop system
that boots often) so I would advise turning it back off once you're
happy with the boot timing.

> For my purposes, Y does seem faster than X. BTW, I also
> customized my Ubuntu kernel the best I could with menuconfig (I'm
> still learning how to configure a kernel) without having
> localyesconfig available. I suppose I could lspci to see exact what's
> on my laptop, but I'm too lazy right now. A caveat is that Canonical
> won't support any custom kernels. It also makes rebuilding proprietary
> modules and drivers (if needed) more difficult. However,
> localyesconfig on my Gentoo desktop did compile in drivers for every
> sound card imaginable, so maybe that script still needs some
> development. I have a sound chip on my motherboard, but I don't have
> any speakers connected, so it doesn't mater anyway.

In the case of loading modules, yes, kernel startup times will be
faster when they're linked into the kernel (by an order of magnitude
if you have many drivers to load) because you're no longer having to
reference the module dependency file recursively and
/etc/modprobe{.d,.conf} for every modprobe call. There are quite a few
slowdowns in this area, actually -- runtime linking of modules into a
kernel is a fairly time consuming task.

As a reference, if I had all of my drivers linked into the kernel
already, I wouldn't spend almost 10 wallclock seconds waiting for the
drivers to be loaded from the initrd -- and that's loading from /ram/,
not disk. Granted, it's probably loading drivers I don't need, but
that's no different than say, Ubuntu or Fedora, which both do pretty
much the same thing as a standard genkernel initrramfs
--all-ramdisk-modules.

As a specific example, Ubuntu loads the PCI hotplugging drivers on
this system, which -- on a laptop -- is completely pointless. =o)

-- 
June Tate-Gans    | Don't try to outweird me, three-eyes. I get stranger things
www.theonelab.com | than you free with my breakfast cereal. -- Zaphod Beeblebrox


More information about the clue-tech mailing list