From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756395AbbCRTga (ORCPT ); Wed, 18 Mar 2015 15:36:30 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:37815 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751074AbbCRTg1 (ORCPT ); Wed, 18 Mar 2015 15:36:27 -0400 Date: Wed, 18 Mar 2015 12:36:22 -0700 From: Dmitry Torokhov To: Tejun Heo Cc: Greg Kroah-Hartman , "Luis R . Rodriguez" , linux-kernel@vger.kernel.org, Arjan van de Ven , Rusty Russell , Olof Johansson , Tetsuo Handa Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe Message-ID: <20150318193622.GH11485@dtor-ws> References: <1421451197-19723-1-git-send-email-dmitry.torokhov@gmail.com> <1421451197-19723-7-git-send-email-dmitry.torokhov@gmail.com> <20150318165618.GB21564@htj.duckdns.org> <20150318174544.GD11485@dtor-ws> <20150318181652.GA25365@htj.duckdns.org> <20150318182318.GF11485@dtor-ws> <20150318182742.GB25365@htj.duckdns.org> <20150318183731.GG11485@dtor-ws> <20150318184550.GC25365@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318184550.GC25365@htj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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