Re: [RFC v1 0/3] driver-core: add asynch module loading support

From: Arjan van de Ven
Date: Sun Aug 31 2014 - 18:48:18 EST

On 8/31/2014 3:45 PM, Dmitry Torokhov wrote:
On August 31, 2014 3:32:19 PM PDT, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote:
On 8/31/2014 1:06 PM, åçé wrote:
Hi, folks

I'm back to this discussion,

The original requirement of my first RFC patchset is mainly for
Android Smartphone use case:

1. We want light on LCD and draw a logo immediately after power key
press(don't consider uboot or lk biotloader here).
2. We want the whole kernel boot fast to give user the Android Launch
3. The modem initialization/reset is slow
4. The Touchpad firmware upgrade is slow
5. We have many cpu cores(up to 8 in latest exynos 5430 and
6. We have few schedulable/parallellizable threads
7. We compiled all of the modules in the kernel(stupid? avoid
modprobe...but lose parallelization in userspace)

So, I think about is that possible to async most of the probes, but
still reserve the requred dependencies to let them still work as

you can boot a whole kernel including all graphics in less than 0.5
seconds, even without this patchset.

You forgot to add "on certain subset of hardware and configuration".


for hardware that takes longer than 0.5s you certainly won't get that.

asynchronous/parallel init helps, but it is not a miracle. Most devices I've worked on
(wide range of hardware from PC to tablets to phones) there tend to be 4 to 5 big guys and a long tail of negliable ones.
the big guys tend to be, even after going in parallel, so large that people who wanted instant boot have to accept
that more miracles are needed.
Like actual work in the driver or device firmware to split work up, rather than an "from the outside" make it asynchronous.

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