From owner-freebsd-arch@freebsd.org Wed Feb 17 19:20:57 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8129AAC01E for ; Wed, 17 Feb 2016 19:20:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 896B01268 for ; Wed, 17 Feb 2016 19:20:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2933AB918; Wed, 17 Feb 2016 14:20:56 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Poul-Henning Kamp , Warner Losh Subject: Re: Starting APs earlier during boot Date: Wed, 17 Feb 2016 10:19:43 -0800 Message-ID: <7708748.E0vxJ7C8cf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <41169.1455702411@critter.freebsd.dk> References: <1730061.8Ii36ORVKt@ralph.baldwin.cx> <41169.1455702411@critter.freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 17 Feb 2016 14:20:56 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:20:57 -0000 On Wednesday, February 17, 2016 09:46:51 AM Poul-Henning Kamp wrote: > -------- > In message , Warner Losh writes: > > >> what is the goal? cleaner code? faster boot? > > > >Two goals were in his original email. > > And I hope that in the longer term we also aim to configure I/O > in parallel ? I'm a bit leery of doing this fully parallel. In particular, users currently depend on the behavior of deterministic names in new-bus (so em0 is always em0 and not sometimes em1). OTOH, I think that we could eventually allow drivers to start doing some of the background scans sooner and only harvest the results at the interrupt config hooks instead of starting the scans and timers at the interrupt config hook (and this is a step towards that). From what I understand, most of our boot time start up delay isn't the new-bus device probe but userland startup. Nevertheless, I think the changes I've proposed here are a prerequisite for even thinking about possibly making device probe more parallel. -- John Baldwin