Thread (102 messages) 102 messages, 22 authors, 2015-10-27

Re: [GIT PULL] On-demand device probing

From: Mark Brown <broonie@kernel.org>
Date: 2015-10-21 16:29:31
Also in: dri-devel, linux-clk, linux-fbdev, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-tegra, lkml

On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
quoted
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.
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.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help