From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756693AbbCRSp7 (ORCPT ); Wed, 18 Mar 2015 14:45:59 -0400 Received: from mail-vc0-f174.google.com ([209.85.220.174]:47640 "EHLO mail-vc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755184AbbCRSpz (ORCPT ); Wed, 18 Mar 2015 14:45:55 -0400 Date: Wed, 18 Mar 2015 14:45:50 -0400 From: Tejun Heo To: Dmitry Torokhov 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: <20150318184550.GC25365@htj.duckdns.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318183731.GG11485@dtor-ws> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Why isn't this transitive through asynchronous ->probe calls? Shouldn't it be? > 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? Thanks. -- tejun