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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4579EAE7.9030201@s5r6.in-berlin.de>
Date:	Fri, 08 Dec 2006 23:44:55 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Luke Kenneth Casson Leighton <lkcl@...l.net>
CC:	Jiri Kosina <jikos@...os.cz>, linux-kernel@...r.kernel.org,
	kernel-discuss@...dhelds.org
Subject: Re: parallel boot device initialisation (kernel-space not userspace)

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/