On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@xxxxxxxxxxxxxx> wrote: > On 10/22/2015 11:53 AM, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> <oops, sent too early...> >>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >>>> 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? >>> >>>> 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). >> 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? >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
