hello darlings,
well i actually followed the FAQ http://www.tux.org/lkml/#s3-17
on this one, and got to try 'do a search' bit, and when searches
for 'parallel boot initialisation' came up with discussions about
parallel ports, and articles on ibm developerworks about sysvinit,
i made the decision to post this anyway.
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.
parallel initialisation is taken care of in user-space by modifying
udev coldplug scripts to watch subsets of the /sys/class/*/event
files disappearing, and by using things like depinit, startpar for
suse, gentoo's parallel startup system (inspired by depinit)
.. but is there _anything_ like this actually in the linux kernel
itself?
i don't believe so, and the reasoning i base that on is that when
i boot my devices (be it a pc or be it an HTC smartphone device
i'm helping to reverse-engineer) the kernel startup log is always
the same, and that multiple messages coming from the same device
(printks) are always grouped together.
i realise that that's slightly faulty reasoning: it could
be that device initialisation is so regular like clockwork that
the output is always the same...
anyway.
now i have to try some things, as an experiment. and i would
like to start with asic3 platform_device, because it contains
dynamically-created lists of child devices and so is a model
example of the kind of dependency-hierarchy that's needed.
so, i seek people's advice on this rather naive approach: simply
set up a workqueue and call schedule_work() on each of the asic3
child platform_devices.
does that sound reasonable, or is it just too simplistic?
l.
p.s. see last few lines of asic3_probe, here, where
platform_add_devices() is called:
http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/soc/asic3_base.c?rev=1.28&content-type=text/x-cvsweb-markup
p.p.s. whilst my 1.2ghz fujitsu laptop (debian/unstable) with depinit
takes only 20 seconds to get from 1st process being run (/sbin/depinit)
to xorg running, it takes ANOTHER 20 seconds to get from kernel boot
up to 1st process (/sbin/depinit) ! that's with a standard debian
kernel - hence my interest in cutting that time to ... well...
under 5 seconds would be nice.
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?
--
Jiri Kosina
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.
l.
--
--
lkcl.net - mad free software computer person, visionary and poet.
--
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/
Stefan Richter wrote:
> Luke Kenneth Casson Leighton wrote:
> 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.)
Would love to see this happen to platform devices...