Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> seems like a horrible, fragile hack.
> >> >
> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> > see as it will show the root cause, not just guessing at this.
> >>
> >>
> >> just fwiw, but when you have a driver that depends on several other
> >> drivers (which in turn depend on other drivers and so on), the amount
> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> probably is some room to optimize by juggling around order drivers do
> >> things in probe.  But that doesn't solve the fundamental problem with
> >> the current state, about probe order having no clue about
> >> dependencies..
> >
> > I can imagine it is a lot of iterations, but how long does it really
> > take?  How many different devices are involved that it takes multiple
> > loops in order to finally work out the correct order?  Where is the time
> > delays here, just calling probe() and having it instantly return
> > shouldn't take all that long.
> 
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.

And how long does that really take?  Numbers please :)

> I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
> 
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Based on the time it takes a modern laptop to boot, 2 seconds is
forever, there has to be something else going on here other than just
calling probe() a bunch of times.  Please use the tools we have to
determine this before trying to change the driver core.

> Just as an aside, the amount of probe-defer adds quite a lot of noise
> when you are trying to debug why some driver doesn't probe
> successfully.  Which itself would be a nice reason to do something
> more clever..

People seem to not like the noise, so let's turn off those messages,
that should speed things up :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/