Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Feb 2016 23:23:17 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: Starting APs earlier during boot
Message-ID:  <CANCZdfqRiEb=fEV1fiE8E9Lr=KYPxDcs5jS2iDW-OowwgoFL3Q@mail.gmail.com>
In-Reply-To: <56C4061B.6010601@freebsd.org>
References:  <1730061.8Ii36ORVKt@ralph.baldwin.cx> <56C4061B.6010601@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 16, 2016 at 10:33 PM, Julian Elischer <julian@freebsd.org>
wrote:

> On 16/02/2016 12:50 PM, John Baldwin wrote:
>
>> Currently the kernel bootstraps the non-boot processors fairly early in
>> the
>> SI_SUB_CPU SYSINIT.  The APs then spin waiting to be "released".  We
>> currently
>> release the APs as one of the last steps at SI_SUB_SMP.  On the one hand
>> this
>> removes much of the need for synchronization while SYSINITs are running
>> since
>> SYSINITs basically assume they are single-threaded.  However, it also
>> enforces
>> some odd quirks.  Several places that deal with per-CPU resources have to
>> split initialization up so that the BSP init happens in one SYSINIT and
>> the
>> initialization of the APs happens in a second SYSINIT at SI_SUB_SMP.
>>
>> Another issue that is becoming more prominent on x86 (and probably will
>> also
>>
> [...]
>
> what is the goal?  cleaner  code? faster boot?


Two goals were in his original email.

(1) Start APs earlier so we can avoid issues with interrupt allocation
(we're currently hitting limits of 160 interrupts when only one is active).
(2) Make allocations more regular between startup and later loading drivers
later. Right now some drivers defer a lot of work so they can allocate
things at a time when all the resources are available. This helps make that
code more regular and actually the same between the different cases.

It has little to do with a faster boot, though it might enable parallel
newbus tree enumeration if that ever gets properly locked.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqRiEb=fEV1fiE8E9Lr=KYPxDcs5jS2iDW-OowwgoFL3Q>