Messages in this thread | | | Date | Mon, 2 Mar 2009 16:59:17 +0100 | Subject | Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel. | From | Kay Sievers <> |
| |
On Mon, Mar 2, 2009 at 15:32, Andreas Robinson <andr345@gmail.com> wrote: > I have finished testing parallel module loading. It looks like a small > kernel with a minimal initramfs and running several instances of insmod > or modprobe in parallel has the best complexity to performance ratio. > > Testing shows that a megamodule is slightly slower than parallel > insmods, so it's not really an option anymore.
That's what I expected, that we would need more changes, to make a mega-module working, because we need parallel code execution here.
> A monolithic kernel with parallelized initcalls is better - about 200 ms > faster than parallel insmods on my test system. However, it comes with a > fairly large set of changes: > > * First, you need a 200-line patch in init/main.c (do_initcalls() and > friends) > > * Then the built-in module dependencies must be calculated properly, eg > with a modified depmod, and added to the build process. > > * Finally "soft" dependencies, i.e dependencies that are not implied by > symbol use, have to be formalized and moved into the kernel somehow. > Right now they're only defined in "install" commands in modprobe.conf. > > So, what do you think, should I keep going? IMHO, the slower userspace > implementation is acceptable since it's so much simpler.
I think so too, and think we are fine using the current standard tools. Also the recent modprobe changes make modprobe very fast by using a binary index to resolve aliases. I think, we can leave the stuff as it is.
Seems with the queued stop-machine()-removal patch, and possibly with the minimized-mutex patch Rusty did, we are fine for now -- at least with the current numbers, and from a distro's point of view.
Most of the "module load delay" distros see, are likely caused by I/O loading the module from disk into the kernel, at least that's what my profiles show. I did all the recent tests (which is a real world udev coldplug) with a ramfs mount containing a copy of the module directory, before running the module autoloader. I can link 40 modules in 0.26 seconds into the kernel with the recent kernel patches.
Thanks for all your testing, it was really helpful, and your patches have been the reason we've found the stop-machine problem. I'm glad that we have real numbers now to point people to. It seems, that we don't need to start fiddling around with hacks in userspace or initramfs tools.
Thanks a lot, Kay
| |