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
properly.
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.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
