lkml.org 
[lkml]   [2015]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] On-demand device probing
    On 10/21/2015 9:27 AM, Mark Brown wrote:
    > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
    >> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
    >
    >>> To be clear, I was saying that this series should NOT affect total
    >>> boot times much.
    >
    >> I'm confused. If I understood correctly, improving boot time was
    >> the key justification for accepting this patch set. For example,
    >> from "[PATCH v7 0/20] On-demand device probing":
    >>
    >> I have a problem with the panel on my Tegra Chromebook taking longer
    >> than expected to be ready during boot (Stéphane Marchesin reported what
    >> is basically the same issue in [0]), and have looked into ordered
    >> probing as a better way of solving this than moving nodes around in the
    >> DT or playing with initcall levels and linking order.
    >>
    >> ...
    >>
    >> With this series I get the kernel to output to the panel in 0.5s,
    >> instead of 2.8s.
    >
    > Overall boot time and time to get some individual built in component up
    > and running aren't the same thing - what this'll do is get things up
    > more in the link order of the leaf consumers rather than deferring those
    > leaf consumers when their dependencies aren't ready yet.

    Thanks! I read too much into what was being improved.

    So this patch series, which on other merits may be a good idea, is as
    a by product solving a specific ordering issue, moving successful panel
    initialization to an earlier point in the boot sequence, if I now
    understand more correctly.

    In that context, this seems like yet another ad hoc way of causing the
    probe order to change in a way to solves one specific issue? Could
    it just as likely move the boot order of some other driver on some
    other board later, to the detriment of somebody else?


    >
    >> While not as dramatic as your results, they are somewhat supportive.
    >> What has changed your assessment that the on-demand device probing
    >> patches will give a big boot performance increase? Do you have
    >> new data or analysis?
    >
    > See above, my understanding was that the performance improvements were
    > more around improved control/predictability/handwave of the boot
    > ordering rather than total time.
    >



    \
     
     \ /
      Last update: 2015-10-21 20:41    [W:4.451 / U:2.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site