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

[Arjan van de Ven <arjan@linux.intel.com>]

On 8/31/2014 3:45 PM, Dmitry Torokhov wrote:
> On August 31, 2014 3:32:19 PM PDT, Arjan van de Ven <arjan@linux.intel.com> 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
>> deaktop
>>> 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
>> MT6595...)
>>> 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
>> expected.
>>
>> 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".

certainly.

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.