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]
Date:	Wed, 21 Oct 2015 08:59:51 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
CC:	Mark Brown <broonie@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <robh+dt@...nel.org>,
	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>,
	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>,
	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,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...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@...r.kernel.org" <linux-usb@...r.kernel.org>,
	linux-fbdev@...r.kernel.org
Subject: Re: [GIT PULL] On-demand device probing

On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown <broonie@...nel.org> wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>>>> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

< snip >

> hope you don't mind I summarize the points taken instead of replying
> to the individual emails. I tried to address all the concerns that
> have been raised again in the cover letter, but I guess I did a bad
> job at explaining myself, so here's another (more in-depth) go at it.

< snip >

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

And then in your reply to Russell's reply to your email you say:

> To be clear, I was saying that this series should NOT affect total
> boot times much.

I'm confused.  If I understood correctly, improving boot time was
the key justification for accepting this patch set.  For example,
from "[PATCH v7 0/20] On-demand device probing":

   I have a problem with the panel on my Tegra Chromebook taking longer
   than expected to be ready during boot (Stéphane Marchesin reported what
   is basically the same issue in [0]), and have looked into ordered
   probing as a better way of solving this than moving nodes around in the
   DT or playing with initcall levels and linking order.

   ...

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

Alexander Holler reported improved boot times for his patch set
in August, which is another approach to ordering probes
(http://article.gmane.org/gmane.linux.drivers.devicetree/133010).
His results for 5 boards was four booted faster, one slightly
slower:

   Some numbers (5 boots on each board, without and with ordering drivers),
   all times are seconds.

   Kirkwood (dockstar, armv5):

   Boot to "Freeing unused kernel memory" (includes mounting the rootfs),
   unordered:
   4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222)
   ordered:
   3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988)
   Time needed to sort (of_init_build_order()):
   0.003024
   Time needed to match drivers to the order (without calling them):
   0.002884

   Beagleboard (rev C4, armv7):

   unordered:
   6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465)
   ordered:
   5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096)
   sorting: 0.021209
   matching: 0.006165

   Beaglebone Black (rev A5, armv7):

   unordered:
   3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076)
   ordered:
   2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446)
   sorting: 0.004769
   matching: 0.004860

   imx6q (armv7):

   unordered:
   3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
   ordered:
   3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)
   sorting: 0.004622
   matching: 0.003868

While not as dramatic as your results, they are somewhat supportive.
What has changed your assessment that the on-demand device probing
patches will give a big boot performance increase?  Do you have
new data or analysis?

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ