# What is faster - Modules in Kernel or udev loads them?

## bastibasti

Hi,

I want to set up a small, second gentoo install, that is not encrypted etc, just in case i need to access the internet quickly etc. Right now iam wondering whether I should modularize everything (USB, Sound, Network, HID) or compile into kernel. Which selection would give me the faster boot? Of course with modules, the kernel would be faster, but i have the feeling that udev sometimes is a bit slower.. Is that right?

----------

## aCOSwt

Well this is a 2 cents opinion that... I share with myself :

1/ You should not be dogmatic ! => i.e. the choice module / kernel should be made depending on the driver.

2/ Things you use rarely should be built as modules. (e.g. things such as cpu firmware update...)

3/ Drivers that are not pretty stable should be built as modules.

As a matter of fact, there should not be any noticeable performance difference.

Some argue around the fact that modular kernels bring a "fragmentation penalty" that I have personally never been able to quantify seriously.

Care should be taken (I have not yet figured out which way...) with alsa drivers for which things are not very clear : Gentoo ALSA howto recommends building as modules while everything you can read in your own configuration files states that Gentoo ALSA devs recommend to build alsa devices in kernel !   :Confused: 

----------

## beandog

 *aCOSwt wrote:*   

> Care should be taken (I have not yet figured out which way...) with alsa drivers for which things are not very clear : Gentoo ALSA howto recommends building as modules while everything you can read in your own configuration files states that Gentoo ALSA devs recommend to build alsa devices in kernel !  

 

To clarify, we recommend you use the drivers with the kernel (modular or built in), *not* the external drivers provided by a package.

----------

## beandog

 *bastibasti wrote:*   

> Hi,
> 
> I want to set up a small, second gentoo install, that is not encrypted etc, just in case i need to access the internet quickly etc. Right now iam wondering whether I should modularize everything (USB, Sound, Network, HID) or compile into kernel. Which selection would give me the faster boot? Of course with modules, the kernel would be faster, but i have the feeling that udev sometimes is a bit slower.. Is that right?

 

There are some things you generally want in the kernel *in case* you might need them some day.  I'd (personally) compile in HID, USB and anything else you'd need in case something breaks.  if USB is modular and it doesn't load properly (for whatever rare reason), then you couldn't use your keyboard / mouse.  Kind of a bummer.

Anything that's not critical though, you can safely load as a module without worrying about it too much (network, sound, etc.)

----------

## Shining Arcanine

I put the kernel's firmware in userland and I noticed an approximate 60 millisecond increase in the average load time of my kernel.

Anyway, I have networking stuff as modules (ethernet, wireless, PPP) and since the wireless is *supposed* to be compiled as a module to resolve the issue of it loading before the file systems are mounted (it prevents it from loading external firmware), I decided to put the rest of the firmware in the kernel out into userland as well, thinking that any improvements to the firmware could be done independently of the kernel version.

Everything else (HID, USB, sound, cryptography, etcetera) is all compiled into the kernel. I was recently interested in making my kernel leaner, so I went nuts pulling stuff out of the kernel that I thought I did not need. I accidentally pulled out my SATA driver because I thought my laptop's BIOS supported AHCI, which it did not, but thankfully I kept the older version of the kernel in /boot with a slightly different name, so I just booted to that and corrected the problem.Last edited by Shining Arcanine on Wed Feb 10, 2010 7:08 pm; edited 1 time in total

----------

## depontius

In general, keeping things as modules gives you more freedom to play with parameters.  In particular you can unload a module and reload it with new parameters.  If it's in-kernel the parameters have to go on the kernel= line in grub or lilo, and they're fixed for the entire boot.  But I'll agree with beandog in that you want the fundamentals of booting to be monolithic in your kernel - basically the keyboard, some display, and enough stuff to access your root partition.

----------

## Shining Arcanine

depontius, do you have any specific suggestions on what should stay out of the kernel? Since I was trying the other day to make my kernel leaner, whether or not to put sound into external modules has been on my mind.

I hate to hijack bastibasti's thread, but since it is a related question and it is on the thread's topic, I figured I would ask here. I originally was not planning to ask.

----------

## depontius

To my way of thinking, sound should definitely be modular - not in-kernel.  On one of my home systems, for the moment I've given up on hd-audio and am running with a PCI sound card.  But last time I was playing with the on-board hd-audio I was tweaking module parameters all over the place, unloading and reloading.  That would have to be rebooting, with attendant waiting, if it were in-kernel.  I gave up on hd-audio quite a while back, and there's every chance that it's gotten better, so one of these days I plan to try it again - again most likely tweaking module parameters.

I have another system with a pair of hvr-1600 capture cards, purchased before Linux support was very stable.  I did a lot of unloading/reloading there too, in the early days.

In general, I have enough built-in to reach my boot disk.  That means the filesystem driver for the root filesystem, (lvm/mdadm, if used) disk drivers, and in my case the ps/2 keyboard.  I make everything else modular that is easy to make modular.

The stated direction by the kernel developers is to make everything modular, eventually doing away with monolithic.  They want to expand the role of "early userspace", initrd/initramfs to the rest of us, in order to push things out of the kernel proper, and have more/better facilities available for system bring-up.  Another way of putting this is that some of the initialization code can be moved from drivers into early userspace.  Back in the old days of DOS and TSRs, one trick with a TSR was to move your initialization code to the end, and throw it away (give it back to DOS) after initialization, when ready to "Terminate and Stay Resident."  What happens to initialization code on Linux device drivers?  Is it thrown away, or does it continue to chew up space?

----------

## toralf

Some years ago I made often the experience that modules are better handled in suspend/resume scenarios (at least at the ThinkPad). Therefore I built as much as possible as modules and I'm happy with this decision until today.

In addition the ability to use different parameter during module load is a nice thing.

----------

## Sadako

 *depontius wrote:*   

> In general, keeping things as modules gives you more freedom to play with parameters.  In particular you can unload a module and reload it with new parameters.  If it's in-kernel the parameters have to go on the kernel= line in grub or lilo, and they're fixed for the entire boot.

 While this is true for the most part, you can still change quite a few of the parameters on the fly via /sys/module/*/parameters.

Just my own 2¢ here, but if you're actually going to be using something upon each boot, then it should be in the kernel unless you have a very specific reason to do otherwise (such as needing to be able to remove the driver from the running kernel), and anything you only use occasionally/rarely should be modules.

As for making your kernel "leaner", it's pointless if whatever you remove will always be loaded as modules anyways.

And as for booting faster, I do believe device detection at least works faster with built in modules, but I don't really have anything to substantiate this.

----------

## aCOSwt

 *beandog wrote:*   

> To clarify, we recommend you use the drivers with the kernel (modular or built in), *not* the external drivers provided by a package.

 

Thanks beandog for clarifying.

I apologize for my potentially poor understanding of English but, to make sure, do you mean that the following message we can read when emerging alsa-utils or at the end of /etc/conf.d/alsasound, v.g. :

 *Quote:*   

> "The Gentoo ALSA developers recommend you to build
> 
> * your audio drivers into the kernel unless the device is hotpluggable
> 
> * or you need to supply specific options (such as model= to HD Audio)."

 

Is obsolete ?

----------

## beandog

 *aCOSwt wrote:*   

>  *beandog wrote:*   To clarify, we recommend you use the drivers with the kernel (modular or built in), *not* the external drivers provided by a package. 
> 
> Thanks beandog for clarifying.
> 
> I apologize for my potentially poor understanding of English but, to make sure, do you mean that the following message we can read when emerging alsa-utils or at the end of /etc/conf.d/alsasound, v.g. :
> ...

 

Yah, either one works, really.  What we actively discourage is just using the alsa-driver package.  Those are modules only, so to remove ambiguity (about which modules: kernel or external) the official response is "use in-kernel drivers, compiled."

Sorry for the confusion.  :Smile: 

----------

## aCOSwt

 *beandog wrote:*   

> "the official response is "use in-kernel drivers, compiled."

 

Thank you once again beandog !

Do not be sorry ! You did not confuse me ! I only confused myself !    :Embarassed: 

I immediately link the one ore two messages I had written about this question to this thread !   :Smile: 

----------

## augury

I've always built the modules into my kernel once they loaded.  I haven't come across any parameters that needed changing.  I've had loading and segfault issues in the past,  besides all the extries that get loaded.

----------

## Shining Arcanine

 *augury wrote:*   

> I've always built the modules into my kernel once they loaded.  I haven't come across any parameters that needed changing.  I've had loading and segfault issues in the past,  besides all the extries that get loaded.

 

Since my post, I have had a change of heart. I now have all of the stuff I can aside from what is needed to mount the root filesystem compiled as modules. Since they need to be loaded as modules, the kernel is forced to mount the file system and the moment that happens, userland starts in parallel, leading to a faster boot. My laptop takes 0.50 to 0.52 seconds according to the kernel messages before userland starts.

----------

## Naib

Force of habit has me building nearly everything as module (only what is needed to boot is in-kernel).

Has the adv if someone is querying something I can do a quick lsmod or lspci -vvv and see exactly what kernel module is in-use. cant do that if it is built-in

for my server, everything compiled in and have disabled module support

----------

## 96140

--Last edited by 96140 on Wed Sep 11, 2013 8:42 am; edited 1 time in total

----------

## Akkara

Moved from Gentoo Chat to Kernel & Hardware.  Fits better here.

----------

## doctork

I must admit I'm a bit mystified at people's concern with boot time with respect to modulurized vs non-modularlized kernels.  I mean how often do you boot your system?  Of the three systems I currently have on line, one has been up for 89 days, one for 8 days and a third for a few hours.  The latter is because I had it powered down while I was out of town for a few days, the 8-days because of a power failure and broken UPS.

I guess it's like comparing 0-60 times with a car.  I can do 0-60 in 4.0 seconds and you can only do 4.2 seconds, so you car is a piece of dung.

It seems to me that the only real questions may be functionality and security -- boot up time is immaterial (for me at least). 

--

doc

----------

## Hupf

 *doctork wrote:*   

> I must admit I'm a bit mystified at people's concern with boot time with respect to modulurized vs non-modularlized kernels.  I mean how often do you boot your system?

 

The great thing about Gentoo is it's versatility. People will use it in ways many others didn't think about before. For example, I'm concerned about boot time on two of my machines: first, my desktop which is rather power-hungry and shouldn't run needlessly overnight. Second, a laptop for notetaking on conferences/seminars which should be usable asap. For the latter, I've achieved a short enough boot time not to inconvenience me anymore (about 10 seconds).

Sure, there's standby mode for these two use cases (which incidentally happens to work on these boxes), but it is not always the most practical solution (the desktop not having a UPS and the laptop battery not lasting more than 1-2 days on standby).

----------

## Link31

Loading modules usually results in a way faster boot, because modules can be loaded in background. If some kernel driver needs several seconds to probe its hardware, it should definitely be compiled as module. Otherwise it would delay the whole boot process and prevent init from being started until the hardware is ready.

That being said, I think the best solution is to compile into the kernel all drivers that load quickly (so you don't have to mess with too many modules and these drivers are always available), and use modules for hardware that needs some time to start up. With this solution, my kernel now boots in less than 1 second, and the time to load the few remaining modules is negligible.

----------

