Message-ID: <20151017202223.GB6602@kroah.com>
Date:	Sat, 17 Oct 2015 13:22:23 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Rob Clark <robdclark@...il.com>
Cc:	Rob Herring <robh+dt@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Russell King <linux@....linux.org.uk>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	David Airlie <airlied@...ux.ie>,
	Terje Bergström <tbergstrom@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	Frank Rowand <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Felipe Balbi <balbi@...com>,
	Jingoo Han <jingoohan1@...il.com>,
	Lee Jones <lee.jones@...aro.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-clk@...r.kernel.org, dmaengine@...r.kernel.org,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux PWM List <linux-pwm@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>
Subject: Re: [GIT PULL] On-demand device probing

On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > 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@...uxfoundation.org> 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@...uxfoundation.org> 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.
> 
> yes, I am aware of the tools.. although so far I spend most of my time
> just trying to get things working in the first place ;-)

And that's where most people stop, if you want to make it fast, you have
to put in more effort, sorry.  Don't expect the driver core to work
around driver bugs for you.

> All I was trying to point out was that Tomeu's figures didn't really
> seem unrealistic.  I mean, given that the average SoC driver probably
> depends on at least one clock and at least one regulator, having to
> probe each driver at least twice seems plausible.  And that having a
> noticeable effect on boot time doesn't seem surprising.  I'm not sure
> that saying 'modern laptop can boot in 2sec' adds much to the
> discussion since I don't think you have quite so much interdependency
> between devices vs random probe order.  I have seen arm devices boot
> to UI in similar times, but that was pre-devicetree days.

2 extra probes add a second to the boot time?  Those sound like really
broken drivers to me :)

thanks,

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

Powered by blists - more mailing lists