Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1250220 > unrolled thread
| Started by | Mark Brown <broonie@kernel.org> |
|---|---|
| First post | 2015-10-18 21:40 +0200 |
| Last post | 2015-10-24 20:00 +0200 |
| Articles | 20 on this page of 82 — 19 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-18 21:40 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-18 21:40 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-18 22:00 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-19 11:50 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 12:00 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-19 13:10 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-19 14:40 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-19 14:50 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-19 17:00 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-19 17:40 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 17:50 +0200
Re: [GIT PULL] On-demand device probing Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2015-10-19 20:30 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 20:50 +0200
Re: [GIT PULL] On-demand device probing Alexandre Courbot <gnurou@gmail.com> - 2015-10-20 01:50 +0200
Re: gpiod API considerations [Was: [GIT PULL] On-demand device probing] Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2015-10-20 09:20 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-20 13:20 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-19 18:00 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-19 23:20 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh@kernel.org> - 2015-10-20 01:00 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-20 09:30 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh@kernel.org> - 2015-10-20 16:20 +0200
Re: [GIT PULL] On-demand device probing Alan Stern <stern@rowland.harvard.edu> - 2015-10-20 16:50 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-20 17:40 +0200
Re: [GIT PULL] On-demand device probing Alan Stern <stern@rowland.harvard.edu> - 2015-10-20 18:10 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-20 18:30 +0200
Re: [GIT PULL] On-demand device probing Alan Stern <stern@rowland.harvard.edu> - 2015-10-20 19:20 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-20 21:40 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-21 01:10 +0200
Re: [GIT PULL] On-demand device probing Jean-Francois Moine <moinejf@free.fr> - 2015-10-21 08:20 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-22 02:30 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-22 11:20 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-27 05:40 +0100
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-21 01:10 +0200
Re: [GIT PULL] On-demand device probing Geert Uytterhoeven <geert@linux-m68k.org> - 2015-10-21 11:00 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-22 01:20 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-19 18:10 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-19 14:40 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 15:20 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-19 16:20 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 16:40 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-19 17:10 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 17:40 +0200
Re: [GIT PULL] On-demand device probing Geert Uytterhoeven <geert@linux-m68k.org> - 2015-10-19 18:30 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 18:50 +0200
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-20 17:50 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-21 06:00 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 10:20 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-21 17:40 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-21 19:00 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 19:30 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-21 20:20 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 20:30 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-22 17:20 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-21 20:10 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-21 20:40 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 22:40 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-22 02:10 +0200
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Mark Brown <broonie@kernel.org> - 2015-10-23 01:40 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-21 18:10 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-21 18:30 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-21 20:30 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-21 23:10 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-21 23:20 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-22 00:00 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-22 11:10 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-22 16:40 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-22 16:50 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-22 17:10 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-23 01:40 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-22 21:00 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-22 21:30 +0200
Re: [GIT PULL] On-demand device probing Tim Bird <tim.bird@sonymobile.com> - 2015-10-23 17:50 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-23 18:40 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-24 15:50 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-25 00:10 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rafael@kernel.org> - 2015-10-25 15:00 +0100
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-26 02:20 +0100
Re: [GIT PULL] On-demand device probing Michael Turquette <mturquette@baylibre.com> - 2015-10-26 12:00 +0100
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-26 14:00 +0100
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rafael@kernel.org> - 2015-10-27 00:40 +0100
Re: [GIT PULL] On-demand device probing "Andrew F. Davis" <afd@ti.com> - 2015-10-25 20:50 +0100
Re: [GIT PULL] On-demand device probing Geert Uytterhoeven <geert@linux-m68k.org> - 2015-10-24 20:00 +0200
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Frank Rowand <frowand.list@gmail.com> |
|---|---|
| Date | 2015-10-21 20:30 +0200 |
| Message-ID | <qm6j8-2HH-23@gated-at.bofh.it> |
| In reply to | #1253037 |
On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > >>> 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. > > Overall boot time and time to get some individual built in component up > and running aren't the same thing - what this'll do is get things up > more in the link order of the leaf consumers rather than deferring those > leaf consumers when their dependencies aren't ready yet. Thanks! I read too much into what was being improved. So this patch series, which on other merits may be a good idea, is as a by product solving a specific ordering issue, moving successful panel initialization to an earlier point in the boot sequence, if I now understand more correctly. In that context, this seems like yet another ad hoc way of causing the probe order to change in a way to solves one specific issue? Could it just as likely move the boot order of some other driver on some other board later, to the detriment of somebody else? > >> 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? > > See above, my understanding was that the performance improvements were > more around improved control/predictability/handwave of the boot > ordering rather than total time. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-21 23:10 +0200 |
| Message-ID | <qm8NX-6qY-1@gated-at.bofh.it> |
| In reply to | #1253114 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: > > Overall boot time and time to get some individual built in component up > > and running aren't the same thing - what this'll do is get things up > > more in the link order of the leaf consumers rather than deferring those > > leaf consumers when their dependencies aren't ready yet. > Thanks! I read too much into what was being improved. > So this patch series, which on other merits may be a good idea, is as > a by product solving a specific ordering issue, moving successful panel > initialization to an earlier point in the boot sequence, if I now > understand more correctly. Yeah, that's my understanding. > In that context, this seems like yet another ad hoc way of causing the > probe order to change in a way to solves one specific issue? Could > it just as likely move the boot order of some other driver on some > other board later, to the detriment of somebody else? Indeed. My general feeling is that it does make the link order stuff more predictable and easier to work with and it does have other merits (in terms of the error reporting, though there's other ways to address that like the one Russell is proposing).
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh+dt@kernel.org> |
|---|---|
| Date | 2015-10-21 23:20 +0200 |
| Message-ID | <qm8XF-6Ci-35@gated-at.bofh.it> |
| In reply to | #1253114 |
On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: >> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> >>>> 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. >> >> Overall boot time and time to get some individual built in component up >> and running aren't the same thing - what this'll do is get things up >> more in the link order of the leaf consumers rather than deferring those >> leaf consumers when their dependencies aren't ready yet. > > Thanks! I read too much into what was being improved. > > So this patch series, which on other merits may be a good idea, is as > a by product solving a specific ordering issue, moving successful panel > initialization to an earlier point in the boot sequence, if I now > understand more correctly. > > In that context, this seems like yet another ad hoc way of causing the > probe order to change in a way to solves one specific issue? Could > it just as likely move the boot order of some other driver on some > other board later, to the detriment of somebody else? Time to display on is important for many products. Having the console up as early as possible is another case. CAN bus is another. This is a real problem that is not just bad drivers. I don't think it is completely ad hoc. Given all devices are registered after drivers, drivers will still probe first in initcall level order and then link order AFAIK. We may not take (more) initcall level tweak hacks, but that is a much more simple change for downstream. Don't get me wrong, I'd really like to see a way to control order independent of initcall level. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Frank Rowand <frowand.list@gmail.com> |
|---|---|
| Date | 2015-10-22 00:00 +0200 |
| Message-ID | <qm9Ao-7mh-39@gated-at.bofh.it> |
| In reply to | #1253262 |
On 10/21/2015 2:12 PM, Rob Herring wrote: > On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote: >> On 10/21/2015 9:27 AM, Mark Brown wrote: >>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >>> >>>>> 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. >>> >>> Overall boot time and time to get some individual built in component up >>> and running aren't the same thing - what this'll do is get things up >>> more in the link order of the leaf consumers rather than deferring those >>> leaf consumers when their dependencies aren't ready yet. >> >> Thanks! I read too much into what was being improved. >> >> So this patch series, which on other merits may be a good idea, is as >> a by product solving a specific ordering issue, moving successful panel >> initialization to an earlier point in the boot sequence, if I now >> understand more correctly. >> >> In that context, this seems like yet another ad hoc way of causing the >> probe order to change in a way to solves one specific issue? Could >> it just as likely move the boot order of some other driver on some >> other board later, to the detriment of somebody else? > > Time to display on is important for many products. Having the console > up as early as possible is another case. CAN bus is another. This is a > real problem that is not just bad drivers. Yes, I agree. What I am seeing is that there continues to be a need for the ability to explicitly order at least some driver initialization (at some granularity), despite the push back against explicit ordering that has been present in the past. > I don't think it is completely ad hoc. Given all devices are > registered after drivers, drivers will still probe first in initcall > level order and then link order AFAIK. We may not take (more) initcall > level tweak hacks, but that is a much more simple change for > downstream. Don't get me wrong, I'd really like to see a way to > control order independent of initcall level. > > Rob Yep, it is not directly ad hoc, just a fortunate side effect in this case. So just accidently ad hoc. :-) -Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-22 11:10 +0200 |
| Message-ID | <qmk2K-69B-29@gated-at.bofh.it> |
| In reply to | #1253298 |
On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote: > On 10/21/2015 2:12 PM, Rob Herring wrote: >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote: >>> On 10/21/2015 9:27 AM, Mark Brown wrote: >>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >>>> >>>>>> 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. >>>> >>>> Overall boot time and time to get some individual built in component up >>>> and running aren't the same thing - what this'll do is get things up >>>> more in the link order of the leaf consumers rather than deferring those >>>> leaf consumers when their dependencies aren't ready yet. >>> >>> Thanks! I read too much into what was being improved. >>> >>> So this patch series, which on other merits may be a good idea, is as >>> a by product solving a specific ordering issue, moving successful panel >>> initialization to an earlier point in the boot sequence, if I now >>> understand more correctly. >>> >>> In that context, this seems like yet another ad hoc way of causing the >>> probe order to change in a way to solves one specific issue? Could >>> it just as likely move the boot order of some other driver on some >>> other board later, to the detriment of somebody else? >> >> Time to display on is important for many products. Having the console >> up as early as possible is another case. CAN bus is another. This is a >> real problem that is not just bad drivers. > > Yes, I agree. > > What I am seeing is that there continues to be a need for the ability > to explicitly order at least some driver initialization (at some > granularity), despite the push back against explicit ordering that > has been present in the past. The important point that I have struggled to explain is that right now for downstreams to influence the order in which devices are probed, they have to carry a substantial amount of patches that cannot be ever upstreamed. This fiddling with initcall levels and link order means changing files that are very frequently changing, increasing the amount of work when rebasing and increasing the probability of regressions after a rebase. This just adds up to other shortcomings of mainline and ends up with the net result of vendors getting stuck with 3.4 kernels on SoCs that start production in 2015. Another consequence is that vendors don't have a chance to upstream their stuff even if they cared. The overarching goal of the project I'm in is to reduce those shortcomings that downstreams have to workaround, to facilitate their involvement upstream. With this series, the order in which devices are probed becomes the order in which they were registered, which is the order in which the devices appear in the FW description of the hw or in the board files (much more predictable, which makes for a more robust process). For DT and board files, which cover a good part of the consumer devices shipped today with Linux, the downstream could just change the order of device nodes and get their display or whatever to probe before any other devices. And even if downstream's hw has a SoC .dtsi that exists in mainline, they could add a step to their build process that automatically reorders the nodes to avoid carrying changes to that DT fragment. 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. 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. Sorry for the rant, Tomeu >> I don't think it is completely ad hoc. Given all devices are >> registered after drivers, drivers will still probe first in initcall >> level order and then link order AFAIK. We may not take (more) initcall >> level tweak hacks, but that is a much more simple change for >> downstream. Don't get me wrong, I'd really like to see a way to >> control order independent of initcall level. >> >> Rob > > Yep, it is not directly ad hoc, just a fortunate side effect in > this case. So just accidently ad hoc. :-) > > -Frank > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2015-10-22 16:40 +0200 |
| Message-ID | <qmpc7-5kr-35@gated-at.bofh.it> |
| In reply to | #1253610 |
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote: > > On 10/21/2015 2:12 PM, Rob Herring wrote: > >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote: > >>> On 10/21/2015 9:27 AM, Mark Brown wrote: > >>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > >>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > >>>> > >>>>>> 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. > >>>> > >>>> Overall boot time and time to get some individual built in component up > >>>> and running aren't the same thing - what this'll do is get things up > >>>> more in the link order of the leaf consumers rather than deferring those > >>>> leaf consumers when their dependencies aren't ready yet. > >>> > >>> Thanks! I read too much into what was being improved. > >>> > >>> So this patch series, which on other merits may be a good idea, is as > >>> a by product solving a specific ordering issue, moving successful panel > >>> initialization to an earlier point in the boot sequence, if I now > >>> understand more correctly. > >>> > >>> In that context, this seems like yet another ad hoc way of causing the > >>> probe order to change in a way to solves one specific issue? Could > >>> it just as likely move the boot order of some other driver on some > >>> other board later, to the detriment of somebody else? > >> > >> Time to display on is important for many products. Having the console > >> up as early as possible is another case. CAN bus is another. This is a > >> real problem that is not just bad drivers. > > > > Yes, I agree. > > > > What I am seeing is that there continues to be a need for the ability > > to explicitly order at least some driver initialization (at some > > granularity), despite the push back against explicit ordering that > > has been present in the past. > > The important point that I have struggled to explain is that right now > for downstreams to influence the order in which devices are probed, > they have to carry a substantial amount of patches that cannot be ever > upstreamed. This fiddling with initcall levels and link order means > changing files that are very frequently changing, increasing the > amount of work when rebasing and increasing the probability of > regressions after a rebase. > > This just adds up to other shortcomings of mainline and ends up with > the net result of vendors getting stuck with 3.4 kernels on SoCs that > start production in 2015. Another consequence is that vendors don't > have a chance to upstream their stuff even if they cared. The > overarching goal of the project I'm in is to reduce those shortcomings > that downstreams have to workaround, to facilitate their involvement > upstream. The init order of drivers has no influence at all on the ability for companies to have their individual drivers merged upstream, please don't be so dramatic about this. Worst case, a vendor keeps a single patch to drivers/Makefile in their tree that reorders things, yes it will get conflicts on every release, but really, it's trivial to maintain if they wish to keep doing this type of thing. Again, it is _not_ the reason that we are living with 2million+ lines of code in vendor kernels. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2015-10-22 16:50 +0200 |
| Message-ID | <qmplM-5wh-9@gated-at.bofh.it> |
| In reply to | #1253610 |
<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 other than that you don't care enough to do the real work and are trying to hack the driver core up instead. > Sorry for the rant, No apologies needed, it's cathartic at times :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-10-22 17:10 +0200 |
| Message-ID | <qmpF7-678-15@gated-at.bofh.it> |
| In reply to | #1253888 |
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote: > <oops, sent too early...> > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > > 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. +100000000000, fully agree. There's too much verbal diarrhoea going on in this thread and no facts. I've been waiting for real data too, and there's not one shred of it, or even a hint that it might appear. So, the conclusion I'm coming to is that there isn't any data to back up the claims made in this thread. If it was such a problem, then in the _eight_ days that this has been discussed so far, _someone_ would have sent some data showing the problem. I think the fact is, there is no data. Someone prove me wrong. Someone post the verifiable data showing that there is a problem to be solved here. Someone show what the specific failure cases are that are hampering vendors moving forwards. Someone show the long boot times by way of kernel message log. Someone show some evidence of the problems that have been alluded to. If no one can show some evidence, there isn't a problem here. :) -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-23 01:40 +0200 |
| Message-ID | <qmxCG-Il-17@gated-at.bofh.it> |
| In reply to | #1253894 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong. Someone post the verifiable data showing that > there is a problem to be solved here. > Someone show what the specific failure cases are that are hampering > vendors moving forwards. Someone show the long boot times by way of > kernel message log. Someone show some evidence of the problems that > have been alluded to. > If no one can show some evidence, there isn't a problem here. :) Yeah, I'm not convinced the timing is *such* a big deal either - I do think that the log spam is a real problem but I think something much less invasive like the interface you proposed is good for addressing that.
[toc] | [prev] | [next] | [standalone]
| From | Frank Rowand <frowand.list@gmail.com> |
|---|---|
| Date | 2015-10-22 21:00 +0200 |
| Message-ID | <qmtfJ-2HW-45@gated-at.bofh.it> |
| In reply to | #1253888 |
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. 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. 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.) -Frank > other than that you don't care enough to do the real work and are trying > to hack the driver core up instead. > >> Sorry for the rant, > > No apologies needed, it's cathartic at times :) > > thanks, > > greg k-h > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2015-10-22 21:30 +0200 |
| Message-ID | <qmtIJ-3vR-7@gated-at.bofh.it> |
| In reply to | #1254106 |
On Thu, Oct 22, 2015 at 11:53:31AM -0700, 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. > > 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. > > 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 agree, there might be some small numbers that this is a problem for, and if so, great, show us the boot logs where things are taking up all of the time, and we can work on resolving those issues. But without hard numbers / details, this all is just random hand-waving, and I don't like making core kernel changes on that basis. And no one else should ever want us to do that either. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Tim Bird <tim.bird@sonymobile.com> |
|---|---|
| Date | 2015-10-23 17:50 +0200 |
| Message-ID | <qmMLo-5JD-21@gated-at.bofh.it> |
| In reply to | #1254106 |
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. > > 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 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. 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.) 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. :-) -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh+dt@kernel.org> |
|---|---|
| Date | 2015-10-23 18:40 +0200 |
| Message-ID | <qmNxM-6UF-21@gated-at.bofh.it> |
| In reply to | #1254681 |
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-10-24 15:50 +0200 |
| Message-ID | <qn7mN-1TY-5@gated-at.bofh.it> |
| In reply to | #1254703 |
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote: > On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> 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). Well, I'm not quite sure why exactly everyone is so focused on probing here. Probing is just one aspect of the fact that we need functional dependencies to be tracked somehow and acted on when necessary. And this is not limited to probing, as I have already said for a few times. Other cases include: system shutdown, system suspend/resume, runtime PM, unbinding of drivers. If there is a functional dependency between two devices (say, B requires A to be present and functional, meaning that the driver of A has to be present and working for the driver of B to be working), all of the above need to be done in a specific order. Today, however, the driver core only knows about structural dependencies and only in the specific parent-child case. So perhaps it's better to start discussing about a solution for the general issue? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-25 00:10 +0200 |
| Message-ID | <qnfaG-4VR-21@gated-at.bofh.it> |
| In reply to | #1255184 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > Well, I'm not quite sure why exactly everyone is so focused on probing here. Probe deferral is really noisy even if it's working fine on a given system so it's constantly being highlighted to people in a way that other issues aren't if you're not directly having problems. There's also the understanding people had that the order things get bound changes the ordering for some of the other cases (perhaps it's a good idea to do that, it seems likely to be sensible?).
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-10-25 15:00 +0100 |
| Message-ID | <qnu01-3FT-9@gated-at.bofh.it> |
| In reply to | #1255255 |
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > Probe deferral is really noisy even if it's working fine on a given > system so it's constantly being highlighted to people in a way that > other issues aren't if you're not directly having problems. > > There's also the understanding people had that the order things get > bound changes the ordering for some of the other cases (perhaps it's a > good idea to do that, it seems likely to be sensible?). But it really doesn't do that. Also making it do so doesn't help much in the cases where things can happen asynchronously (system suspend/resume, runtime PM). If, instead, there was a way to specify a functional dependency at the device registration time, it might be used to change the order of everything relevant, including probe. That should help to reduce the noise you're referring to. If the dependency could only be discovered at the probe time, the order of things might be changed in response to letting the driver core know about it rather than "just in case", which should be more efficient. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-26 02:20 +0100 |
| Message-ID | <qnEC5-1Pr-1@gated-at.bofh.it> |
| In reply to | #1255400 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote: > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). Yeah, people seem to have that impression though. :( > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. This links back to the idea of having generic support for pre-probe actions which is also generally useful (the ability to do things like power on regulators for devices on enumerable buses so they can be enumerated as standard).
[toc] | [prev] | [next] | [standalone]
| From | Michael Turquette <mturquette@baylibre.com> |
|---|---|
| Date | 2015-10-26 12:00 +0100 |
| Message-ID | <qnNFn-7br-1@gated-at.bofh.it> |
| In reply to | #1255400 |
Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > > >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that > > other issues aren't if you're not directly having problems. > > > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). > > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. Taking it a step further, if functional dependencies were understood at link-time then we could optimize link order as well. There are probably lots of optimizations if we only made the effort to understand these dependencies earlier. Constructing the device/resource dependency graph before the device ever boots sounds interesting to me. Regards, Mike > > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. > > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-26 14:00 +0100 |
| Message-ID | <qnPxw-8lm-13@gated-at.bofh.it> |
| In reply to | #1255817 |
On 26 October 2015 at 11:51, Michael Turquette <mturquette@baylibre.com> wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. > > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. Alexander Holler has been looking at that for some time already. Regards, Tomeu > Regards, > Mike > >> >> If the dependency could only be discovered at the probe time, the >> order of things might be changed in response to letting the driver >> core know about it rather than "just in case", which should be more >> efficient. >> >> Thanks, >> Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-10-27 00:40 +0100 |
| Message-ID | <qnZwS-66Z-9@gated-at.bofh.it> |
| In reply to | #1255817 |
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette <mturquette@baylibre.com> wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. Do you mean the kernel link time or something else? At least in some cases the dependency information won't be known at that time, so we need a way to record a dependency at the time it becomes visible to us anyway. > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. That's only practical if you build the kernel for a specific device. If you want a generic binary that can work with multiple different devices, that graph may very well be different for each of them. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.kernel
csiph-web