Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Feb 2012 13:08:52 -0800
From:      Doug Barton <dougb@FreeBSD.org>
To:        Alex Goncharov <alex-goncharov@comcast.net>
Cc:        Tom Evans <tevans.uk@googlemail.com>, hackers@freebsd.org
Subject:   Re: 8 to 9: Kernel modularization -- did it change?
Message-ID:  <4F42B664.4070400@FreeBSD.org>
In-Reply-To: <E1RzWVd-000MHj-AD@hans3>
References:  <CAOjFWZ6WM1bLEwaBiUE50Gj4MrwxefDWFb85ecRtYkSDuZ0erg@mail.gmail.com> <mailpost.1329495670.7246668.67851.mailing.freebsd.hackers@FreeBSD.cs.nctu.edu.tw> <4F3E8225.9030501@FreeBSD.org> <E1RyRKJ-000Ioa-Ec@hans3> <4F3E8C26.3080900@FreeBSD.org> <E1RyRq0-000Iqy-3l@hans3> <4F3EA5F2.9070804@gmail.com> <E1RyTZo-000J0R-0Y@hans3> <4F3EAE5F.6070903@gmail.com> <E1RyUv6-000J5e-0E@hans3> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <CAFHbX1KO7mc0zhOGMHrKmAt%2BBnuqUM14RKCaug8RvaeCYnXAzw@mail.gmail.com> <E1RzWVd-000MHj-AD@hans3>

next in thread | previous in thread | raw e-mail | index | archive | help
On 02/20/2012 08:54, Alex Goncharov wrote:
> ,--- You/Tom (Mon, 20 Feb 2012 14:44:09 +0000) ----*
> | On Sat, Feb 18, 2012 at 1:14 AM, Doug Barton <dougb@freebsd.org> wrote:
> | > Because loading modules through loader.conf is
> | > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called
> | > kld that will load the specified modules after disks are mounted. This
> | > is at least an order of magnitude faster.
> 
> | Come off it, loading modules from loader.conf takes seconds off disk,
> | out of the 2+ minute total boot up.

In my testing, which I posted around the time that I wrote and added the
kld script, each module takes "a second or two" from the boot loader,
whereas the 5 modules I load routinely take less than a second in total.

> | There may be benefit on slow
> | media, but in the general case I see no benefit (which might explain
> | why not many people are bothering to change their working configs to
> | save <2s on bootup).

So don't make the change. I don't really care how much time you want to
waste while your system boots. :)

> Seconded.
> 
> As many have noticed, the "veeeeeerrrrryyyyyy sssssllllloooooowwwwww"
> and "order of magnitude faster" claim has not been supported by
> empirical evidence in this discussion. 

That's because I already posted it a long time ago, and it's been
confirmed by others on many occasions. Short version, the mechanism used
by the loader to pull the bits off the disk is *always* going to be
slower than reading them from the booted disk. I understand that you
guys are new to this topic, so I'm happy to give you time to catch up,
test it for yourself, etc.

> If instead of .002 sec the module loading takes .02,

It's closer to 1.5 seconds per module, on average.

> nobody cares.

And here's where you're making the biggest mistake. You're assuming that
the only use case that's important is the one that you're familiar with.
This isn't even close to true. For embedded systems speeding up the boot
is critical. It's also important for people who use FreeBSD systems to
make money, where every second of downtime translates to dollars lost.

> The fact that one can spread configuration and initialization
> parameters across several non-hierarchically-related entities
> (rc.conf, loader.conf, device.hints) somewhat arbitrarily, seems not
> right to me.

A) It's not arbitrary, and
B) That's an emotional response to a technical topic. Take a step back
and try to understand the system, and why it's designed the way it is,
separate from your emotions about it. That will help you make better
technical decisions.

> Personally, I don't care about winning 10 seconds on a boot

So, don't use kld_list. It won't hurt *my* feelings one bit. :)


Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F42B664.4070400>