From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbbJQThV (ORCPT ); Sat, 17 Oct 2015 15:37:21 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:34722 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750759AbbJQThU (ORCPT ); Sat, 17 Oct 2015 15:37:20 -0400 MIME-Version: 1.0 In-Reply-To: <56229E1A.8010803@ahsoftware.de> References: <1445102067-11519-1-git-send-email-holler@ahsoftware.de> <1445102067-11519-5-git-send-email-holler@ahsoftware.de> <5622956F.80408@ahsoftware.de> <56229B0B.80100@ahsoftware.de> <56229E1A.8010803@ahsoftware.de> Date: Sat, 17 Oct 2015 12:37:19 -0700 X-Google-Sender-Auth: qmP2C0U9K0sPBiOhhAcVEMSdhAI Message-ID: Subject: Re: [PATCH 04/14] init: deps: order network interfaces by link order From: Linus Torvalds To: Alexander Holler Cc: Linux Kernel Mailing List , Andrew Morton , Greg Kroah-Hartman , Russell King , Grant Likely Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 17, 2015 at 12:14 PM, Alexander Holler wrote: > > It's impossible to take it into account because I don't want to miss the > parallelize functionality. And without that, all the stuff doesn't offer > enough benefits to be worse the effort but just adds some time necessary to > do the sorting. It might solve the deferred probe problems, but without much > benefit. Quite frankly, the alleged advantage of parallelization of the init sequence is *very* questionable. But even if you were to want to parallelize things at that level, you'd still (a) want to make *that* a flag (to debug) and make it opt-in (so you'd have another "this module can be done in parallel" marker) (b) end up with all the other drivers *not* being parallel, because they were all written to not have everything happen at once. (c) want to avoid the whole flag-day things so even then you'd want to sort everything using that topological stable sort, so that you can sanely mix things, and then mark individual drivers as "I'd like to run in parallel with the rest of the init sequence". The main thing that being parallel would change is likely that you'd also have to add some kind of "I'm done" completion for each module (or dependency point), so that things that depend on other things (that have *started*) can explicitly wait for those other things to actually end. We have something like that for our "sync" points right now with the whole asynchronous machinery. It's somewhat general (although I think almost all users end up just doing "async_synchronize_full()", even though we do have a cookie-based one) and I suspect the cookie-based one could be used for individual drivers and their completions. But I really think the whole "do initcalls in parallel" is a very bad idea _regardless_ of anything else. We almost never actually have initcalls that really take a lot of time, and when we do, we already handle the big ones with the async machinery, which is actually a lot more powerful and flexible than some "run initcalls in parallel", exactly because you can run *parts* serially (like basic discovery), and then run other parts asynchronously (like "spin up disk" or "wait for power stable" or whatever - *after* you have discovered the device). So I personally think our async thing is much more powerful and useful than some random "let's run initcalls in parallel". Linus