On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird [off-list ref] wrote:

On 10/22/2015 11:53 AM, Frank Rowand wrote:

quoted

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:

quoted

<oops, sent too early...>

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:

quoted

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent?  What driver is causing long
delays?  Why is the long-delay-drivers not being done in their own
thread?  And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?

quoted

Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.

No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.

And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster.

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

It's very common to want to get the display up before the
rest of the system.  So wanting to accelerate one part of the boot
at the expense to the rest of the system is a valid use case.
Deferred initcalls, which is out of tree primarily because it requires
the type of manual tweaking that Tomeu describes, specifically
addressed this issue.

Agreed and other folks will want other things up first. But it seems
we are getting lucky with link order with the speed ups in this case.
We need a way to specify priority of probing devices. If we have that
piece, then all this plumbing can be used. A simple solution would be
looking at stdout-path to get the console device to probe. That would
be trivial to add on top of this. That may work for the display too,
but you may not want the console on the display. That wouldn't work
for CAN bus either, but then I'm not sure there is a generic solution
for its requirements (respond within 50ms IIRC).

quoted

Just to get side-tracked, one other approach at ordering to reduce
deferrals reported a modest boot time reduction for four boards and a
very slight boot time increase for one other board.) The report of boot
times with that approach was in:

  http://article.gmane.org/gmane.linux.drivers.devicetree/133010

from Alexander Holler.

I have not searched further to see if there is more data of boot time
reductions from any of the other attempts to change driver binding
order to move dependencies before use of a resource.  But whether
there is a performance improvement or not, there continues to be
a stream of developers creatively impacting the binding order for
their specific driver(s) or board.  So it seems that maybe there
is an underlying problem, or we don't have adequate documentation
explaining how to avoid a need to order bindings, or the
documentation exists and is not being read.

Well, I have probe order problems unrelated to boot time, that
I solved by resorting to putting stuff into modules and loading
them post-boot.  So I'd be interested in easy solutions to managing
boot order in mainline.

I take it that this series doesn't help those problems?

quoted

I have been defaulting to the position that has been asserted by
the device tree maintainters, that probe deferrals work just fine
for at least the majority of cases (and is the message I have been
sharing in my conference presentations about device tree).  But I
suspect that there is at least a small minority of cases that are not
well served by probe deferral.  (Not to be read as an endorsement of
this specific patch series, just a generic observation.)

I've been worried about DT overhead adding to boot time for a while.

Always beating up DT... ;) Yes, I'm sure there is some overhead, but
looking at bootgraph there's much longer items not related to DT (USB,
MMC and anything over I2C seem to be typical). With DT we lost most
control of the order, and at the same time we added a load of new
subsystems that are dependencies.

And IMHO probe deferral is just about the lamest way to solve boot
order dependencies I can imagine, from a computer science perspective.
(Well, there's a certain elegance to it, but it's a stupid "make
everything re-doable, back up and start over, time-wasting" elegance.)

Exactly. That was a large part of my accepting it.

However, when Android takes 35 seconds to boot, and most people almost never
cold-boot your product, a few seconds of kernel time-wasting on
cold-boot seem less important. Alas, when I started working on mobile
phones I stopped caring much about boot time.

Thus, I've never worried about the DT overhead enough to actually
measure it, as requested by Greg.  So I'll just shut up now. :-)

That would be a challenge to measure since it is distributed.

Rob