Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1249422
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [GIT PULL] On-demand device probing |
| Date | 2015-10-17 21:00 +0200 |
| Message-ID | <qkERY-67y-17@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <qkCwN-2Pq-13@gated-at.bofh.it> <qkCZP-3ox-7@gated-at.bofh.it> <qkDVU-4Kw-17@gated-at.bofh.it> <qkEoW-5xv-1@gated-at.bofh.it> <qkEIh-5Va-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@linuxfoundation.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@linuxfoundation.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. > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-14 10:40 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-14 11:30 +0200
[GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-15 13:50 +0200
Re: [GIT PULL] On-demand device probing Olof Johansson <olof@lixom.net> - 2015-10-16 23:30 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 17:30 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 09:00 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 17:10 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 17:50 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 18:30 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 19:00 +0200
Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 20:00 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 20:30 +0200
Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 20:50 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 21:00 +0200
Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 21:40 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 22:30 +0200
Re: [GIT PULL] On-demand device probing Noralf Trønnes <noralf@tronnes.org> - 2015-10-17 21:10 +0200
Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 21:50 +0200
csiph-web