Re: [RFC PATCH] Multi-threaded device probing

From: H. Peter Anvin
Date: Tue Jul 25 2006 - 17:31:01 EST

Greg KH wrote:
During the kernel summit, I was reminded by the wish by some people to
do device probing in parallel, so I created the following patch. It
offers up the ability for the driver core to create a new thread for
every driver<->device probe call. To enable this, the driver needs to
have the multithread_probe flag set to 1, otherwise the "traditional"
sequencial probe happens.

Note that this patch does not actually enable the threaded probe for any
busses, as that's very dangerous at this point in time, without the
different bus authors trying it out and verifying that it does work

I did enable this for both USB and PCI and shaved .4 seconds off of the
boot time of my tiny little single processor laptop. The savings of my
4-way workstation is much greater, but things start to happen so fast we
miss the root disk, as init starts before the disks are finished being
initialized. I have some hacks to work around this right now, but I'll
hold off on posting them before I make sure they work properly (breaking
booting of people's machines isn't the best way to get them to accept
new features...)

Anyway, have fun playing around with this if you want, I'll be adding
this to the next -mm, but you will have to enable the bit on your own if
you want to see any speedups.

This is very interesting in the context of a few discussions I had at OLS about klibc; there are people who would like initramfs to be accessible *before* device probing is done, so that drivers can access firmware and possible hotplug from the initramfs during the driver initialization. We could even invoke (k)init at this point; this would require a) having a system call or device that would allow kinit to block until device probing was complete, and b) a way to handle /dev/console -- there are several different ways to deal with it; it's mostly a matter of picking a good one.

Note that we don't need device drivers for userspace -- we only need VM, VFS and scheduler initialization.

Multithreaded device initialization is a great idea, especially since many devices require delays during initialization, sometimes on the order of seconds.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at