Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Feb 2016 10:19:43 -0800
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-arch@freebsd.org
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, Warner Losh <imp@bsdimp.com>
Subject:   Re: Starting APs earlier during boot
Message-ID:  <7708748.E0vxJ7C8cf@ralph.baldwin.cx>
In-Reply-To: <41169.1455702411@critter.freebsd.dk>
References:  <1730061.8Ii36ORVKt@ralph.baldwin.cx> <CANCZdfqRiEb=fEV1fiE8E9Lr=KYPxDcs5jS2iDW-OowwgoFL3Q@mail.gmail.com> <41169.1455702411@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, February 17, 2016 09:46:51 AM Poul-Henning Kamp wrote:
> --------
> In message <CANCZdfqRiEb=fEV1fiE8E9Lr=KYPxDcs5jS2iDW-OowwgoFL3Q@mail.gmail.com>, 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7708748.E0vxJ7C8cf>