The eudev project launches

Posted Dec 17, 2012 4:58 UTC (Mon) by demarchi (subscriber, #67492)
Parent article: The eudev project launches

> The introduction of kmod eliminated the 0.01 ms fork() overhead, and
> consequently required each module to be loaded sequentially. This
> imposes an overhead of 10 to 20 milliseconds times the number of
> modules, which is asymptotically worse than what it replaced. A feature
> of kmod intended to address that placed all modules into a single file,
> which would actually make things faster. However, none of our users use
> it and all of our users would suffer from it.

This paragraph is full of misconceptions.

a) kmod didn't eliminate the fork overhead, but rather the exec one (and not only the time of the exec syscall, but also the config parsing, index loading, etc). It's particularly important when the module is already loaded and all you want is to check it is actually loaded.

b) there's no way to load modules in parallel. Please check the kernel implementation of module_init before stating things like above. Exec'ing several instances of modprobe doesn't mean you are loading the modules in parallel.

c) Exec'ing modprobe is no better than using the library. Saying that while exec'ing modprobe you have all modules in "10ms ~ 20ms" vs "10ms ~ 20ms times the number of modules" is not true. And the use of "which is asymptotically worse than what it replaced" shows intention to distort data. Please, publish your measurements.

d) There's no such "all modules in a single file" feature in kmod. And if it had it would have *nothing* to do to any of the problems you mentioned. What udev uses is a cached version of resources, meaning config, index, etc. To be fair, there's such an item in the TODO of kmod, but it was from its early days and I'm totally baffled about you thinking that was implemented.

> In addition, the manner in which kmod was integrated has implications
> beyond speed regressions. The use of kmod by udev permits a buggy kernel
> module (possibly interacting with bad hardware) to hang in module_init.

Do you mean the firmware issue? It was fixed in different places, both in kernel and udev. Not an issue anymore. Otherwise, exec'ing modprobe doesn't give you any other guarantee the module will not fail on module's init.

to post comments

The eudev project launches

Posted Dec 17, 2012 11:13 UTC (Mon) by gidoca (subscriber, #62438) [Link] (3 responses)

There is no way to load modules in parallel, but it would be possible to read the .ko files from disk in parallel. I think that's what happens when you call multiple instances of modprobe in parallel.

The eudev project launches

Posted Dec 17, 2012 15:05 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

Why would you want that? If it's spinning rust then it's not a good idea at all and if it's an SSD then speedup will be unnoticeable.

The eudev project launches

Posted Dec 17, 2012 17:00 UTC (Mon) by gidoca (subscriber, #62438) [Link]

I'm not sure. Presumably you could read a module from disk while another is being init_module()d, which might make things slightly faster. I don't have enough insights into the inner workings of udev, kmod, modprobe and the kernel to tell if that would work, though. Also, it wouldn't have asymptotically better complexity, as was claimed by Richard.

The eudev project launches

Posted Dec 17, 2012 17:23 UTC (Mon) by s0f4r (guest, #52284) [Link]

Readahead already takes care of this, so there is little to no gain from duplicating the same functionality in udev.

The eudev project launches

Posted Dec 17, 2012 19:00 UTC (Mon) by vrfy (guest, #13362) [Link]

> The introduction of kmod eliminated the 0.01 ms fork() overhead, and
> consequently required each module to be loaded sequentially.

Sequentially?

Udev's workers are all fully async, run in parallel, and can call
module_init() all at the same time.

I really wonder how much you guys know about the project you try to maintain. :)

> This
> > imposes an overhead of 10 to 20 milliseconds times the number of
> > modules, which is asymptotically worse than what it replaced.

I mean, sure, I love simple explanations, but some things just aren't
that simple. This is as wrong as it can get. :)

The eudev project launches

Posted Dec 21, 2012 7:50 UTC (Fri) by felipec (guest, #75494) [Link]

I have a hang that happens very often, and it's not the "firmware issue".