linux-kernel - Re: [GIT PULL] On-demand device probing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56229BCC.9050603@tronnes.org>
Date:	Sat, 17 Oct 2015 21:04:44 +0200
From:	Noralf Trønnes <noralf@...nnes.org>
To:	Rob Clark <robdclark@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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


Den 17.10.2015 20:45, skrev Rob Clark:
> 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.  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.

Are you saying that the total boot time is increased by 2 sec due to
deferred probing, or that display initialization is happening 2 sec
after it's first try?

--
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/