From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757183AbbCRWPh (ORCPT ); Wed, 18 Mar 2015 18:15:37 -0400 Received: from mail-ig0-f180.google.com ([209.85.213.180]:33602 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756908AbbCRWPf (ORCPT ); Wed, 18 Mar 2015 18:15:35 -0400 Date: Wed, 18 Mar 2015 15:15:30 -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: <20150318221530.GK11485@dtor-ws> References: <20150318182318.GF11485@dtor-ws> <20150318182742.GB25365@htj.duckdns.org> <20150318183731.GG11485@dtor-ws> <20150318184550.GC25365@htj.duckdns.org> <20150318193622.GH11485@dtor-ws> <20150318195141.GD25365@htj.duckdns.org> <20150318202605.GI11485@dtor-ws> <20150318210226.GE25365@htj.duckdns.org> <20150318214126.GJ11485@dtor-ws> <20150318215028.GF25365@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318215028.GF25365@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 05:50:28PM -0400, Tejun Heo wrote: > Hello, Dmitry. > > On Wed, Mar 18, 2015 at 02:41:26PM -0700, Dmitry Torokhov wrote: > > You are over-stating the boot order guarantees that storage provides. > > Yes, you can scan devices and partitions simultaneously on the same > > controller, but it will break if controllers are registered in different > > order. And if you are delaying registering cone controller because > > another that you consider "first" has not done probing, you are stalling > > the boot process. It may be OK for "leaf" devices, which disks are > > usually are, bit not when you delaying initialization of a device that > > is in a middle of the device tree. > > Can't we make it "transitive"? Split ->probe() into two parts so that > attaching the leaf devices run from the completion part of the split > ->probe(). Sure, a lot of userlands we have nowadays can handle probe > order changing but we stil have use cases where the order matters. > Why introduce two separate behaviors when we can make the pararell > ordering transitive? So let's say that we we have 2 devices D1 and D2 which have children C1 and C2 with leaves L1 and L2: Device Probe time D1 5 D2 1 C1 2 C2 4 L1 1 L2 1 If we run fully async we will need 8 units to probe everything (max(D1+C1+L1, D2+C2+L2)). With pausing at each level we'd need 10 units (max(D1, D2) + max(C1, C2) + max(L1, L2). > > Doing things based on a big switch is going to create two largely > separate modes of operations. For a lot of cases, the gain in boot > time might not be enough to turn on the switch and we sure can't > default to turning it on. This is a deviation we can avoid with > reasonable amount of effort. The trade-off seems pretty clear to me. As I mentioned, the benefit / trade-off depends on your point of view. For servers nobody would care. For consumer devices it is very important. Thanks. -- Dmitry