Re: parallel boot device initialisation (kernel-space not userspace)

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Luke Kenneth Casson Leighton wrote:
> On Fri, Dec 08, 2006 at 05:38:47PM +0100, Jiri Kosina wrote:
>> On Fri, 8 Dec 2006, Luke Kenneth Casson Leighton wrote:
>>
>>> I Have A Great Idea(tm) and would like to describe it concisely to see 
>>> if anyone likes it and hopefully hasn't thought of it before so i'm not 
>>> consuming people's time. The idea is: parallel device initialisation of 
>>> built-in modules, to reduce kernel boot time.
>> Have you looked at CONFIG_PCI_MULTITHREAD_PROBE which is already present 
>> in recent kernels?
>  
>   ah _ha_.  thank you!
> 
>  honestly? no - because the small devices i'm compiling for don't have a
>  pci bus, ha ha :)
> 
>  but seriously - thank you for pointing that out, i'll definitely
>  investigate it.

Parallelized initialization needs to be added for one bus after another.
The driver core has infrastructure for it (struct
device_driver.multithread_probe; it has been suggested to move this flag
into struct bus_type). CONFIG_PCI_MULTITHREAD_PROBE actually just enables
this flag for the generic driver part of PCI drivers. The SCSI core as
another example has now infrastructure for parallelized asynchronous bus
scanning too and SCSI low-level drivers are being be converted to it.

Your thought to pick one subsystem and implement multithreaded probing is
exactly the way to go. If the subsystem is already properly using the
driver core, part of what's needed is already in place. You "merely" have
to look out for proper access to shared resources, and maybe synchronization
of the final step in initialization... (Like in case of the SCSI subsystem.
People usually want to wait for all scanning threads to finish before the
system proceeds to mount filesystems.)
-- 
Stefan Richter
-=====-=-==- ==-- -=---
http://arcgraph.de/sr/