Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

[Dmitry Torokhov]

On Wed, Mar 18, 2015 at 02:45:50PM -0400, Tejun Heo wrote:
> On Wed, Mar 18, 2015 at 11:37:31AM -0700, Dmitry Torokhov wrote:
> > I do not believe that we will be able to activate asynchronous probing
> > by default in the next 2, 3, 4 merge windows: distributions will have to
> > try and use it and see if they are ready for it. However there are
> 
> Async provides strict completion ordering which storage drivers
> already make use of to preserve probe order.

Only SCSI. The rest of them do not as far as I can see. And I do not
think they should (and nor SCSI) after we enable everything to async.

>  Why isn't this
> transitive through asynchronous ->probe calls?  Shouldn't it be?

No, I think it should not.

> 
> > drivers (slow to probe, usually input) that we do know are OK to be
> > probed asynchronously even today (because the rest of the infrastructure
> > dealing with input has been converted to deal with hotplug and devices
> > coming and going in random order at random points of time). Thus
> > whitelist is useful for now to reduce boot times even if the rest of the
> > system is probed synchronously because you are not quite ready for your
> > root device to jump around.
> 
> Yeah, I can see the short term benefits but at the same time I don't
> think this is a healthy long term strategy unless someone really tries
> to make it happen that three four merge window is gonna stretch
> forever.  If storage drivers are problematic, why not just blacklist
> them?

Because they are not inherently problematic. I mean from the kernel POV
they work fine, the question is if your userspace can deal with them or
not. For example ChromeOS userspace is fine.

For the record the stuff I had (still have) issues with when enabling
fully async probing on the board I tried were serial and OF-based
regulators.

Thanks.

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