From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755127AbbCRSXZ (ORCPT ); Wed, 18 Mar 2015 14:23:25 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:35168 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750905AbbCRSXX (ORCPT ); Wed, 18 Mar 2015 14:23:23 -0400 Date: Wed, 18 Mar 2015 11:23:18 -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: <20150318182318.GF11485@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318181652.GA25365@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:16:52PM -0400, Tejun Heo wrote: > Hello, > > On Wed, Mar 18, 2015 at 10:45:44AM -0700, Dmitry Torokhov wrote: > > Without the debug options how can we do that? I will definitely not be > > able to go through all the in-tree drivers myself and see if they can be > > asynchronously probed or not. The most I can do is to try enabling the > > option on our side and fixing the drivers/subsystems that fail with > > asynchronous probing. This will be iterative process for some time and > > then we'll drop the debug option and flip the flag to do asynchronous > > probing by default. > > Is this even useful for most drivers? Define useful. In my tests I was able to shave 2-3 seconds (out of 8-10) of boot time for the board I was trying it on. Useful for our use case, not so useful for others. > If not, let's just stick with > whitelisting. If it is useful, I worry that we're quite unlikely to > build working blacklist with this approach. idk, having both white > and blacklists tend to end badly. I will try fixing the amd64_edac driver, but I consider FORCE_SYNCHRONOUS at the moment as an aid for use when trying fully-asynchronous probing. OTOH I wonder how many more drivers do what edac does and try to do post-binding setups... and whether it makes sense to actually try and fix them. Thanks. -- Dmitry