Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

First version of kmod released

Posted Dec 16, 2011 14:45 UTC (Fri) by horras23 (guest, #81864)
Parent article: First version of kmod released

'kmod-lsmod' and 'kmod-modprobe' seem to be a lot slower than 'lsmod' and 'modprobe' when run in a bash loop. Is this due to fact that kmod is new or because I'm a total noob that has no idea what he's doing? :)

(Log in to post comments)

Posted Dec 17, 2011 5:36 UTC (Sat) by cwillu (subscriber, #67268) [Link]

The gains come from not needing to start a new process for each invocation. Running them from bash negates this entirely. The binary itself being slower probably reflects performance tuning in the old modprobe that hasn't been duplicated in the new one, and I believe there was a mention above that there's some additional debugging temporarily enabled to help uncover any lingering problems.

First version of kmod released

Posted Dec 18, 2011 18:47 UTC (Sun) by demarchi (subscriber, #67492) [Link]

Well... that is not a fair benchmark. For the one-module case you'll have very similar times with kmod-modprobe and modprobe. There are somethings to note here:

1) The current implementation kmod-modprobe is temporary and only serves so we tune the libkmod API. We'll replace it once we have a more complete API
2) For the case 'lookup of 1 and only 1 module' you'll have very similar times with kmod-modprobe and modprobe. If you are getting greater times for kmod-modprobe it's probably because you are not running from the git tree and as it uses libtool, ./tools/kmod-modprobe is a script. If you want to benchmark there with such a small workload you'll to manually run the binary, which means 'LD_LIBRARY_PATH=$PWD/libkmod/.libs/ ./tools/.libs/kmod-modprobe'
3) When you are doing a lookup of several modules (like udev does), a more fair comparison would be to call modprobe several times with '-R' argument vs calling 'kmod-modprobe -Ra' once with all the modules. Here it shows an improvement of ~ 2.5 times.

I'll talk about this in a later post (maybe together with kmod 2).

Again, the focus is not speed, but for the use case of udev it's a nice side effect.

First version of kmod released

Posted Dec 18, 2011 21:19 UTC (Sun) by jcm (subscriber, #18262) [Link]

Indeed. It doesn't matter (within reason) how long a single modprobe call on the command line takes so long as the case where there are (potentially) hundreds of calls is reasonable. At this point, most users only experience loading of modules in response to udev handled events, so it's reasonable (now) to focus on udev as the primary user and have a library, and preserve compatible tools for the occasional loading of modules by hand - by a developer, by an admin, or in a few cases where a module is not yet exposing aliases or other means to be loaded automatically on certain platforms. I really like the new library.