diff options
| author |   visa <visa@openbsd.org> | 2020-02-25 16:55:33 +0000 |
|---|---|---|
| committer | visa <visa@openbsd.org> | 2020-02-25 16:55:33 +0000 |
| commit | 1ab6845c7fa458f2367d6012c7c943bea84ab9dd (patch) | |
| tree | 7d61b84f612851772df45bc9b3ff6fc2b32734ba /sys/kern/init_main.c | |
| parent | malloc(a * b) -> reallocarray(NULL, a, b) (diff) | |
| download | wireguard-openbsd-1ab6845c7fa458f2367d6012c7c943bea84ab9dd.tar.xz wireguard-openbsd-1ab6845c7fa458f2367d6012c7c943bea84ab9dd.zip | |
Start the SMR thread when all CPUs are ready for scheduling. This
prevents the appearance of a "smr: dispatch took N seconds" message
during boot when there is an early smr_call(). Such a call can happen
with mfii(4). The initial dispatch cannot make progress until
smr_grace_wait() can visit all CPUs.
This fix is essentially a hack. It makes use of the fact that there
is no hard guarantee on how quickly the callback of smr_call() gets
invoked. It is assumed that the SMR call backlog does not grow large
during boot.
An alternative fix is to make smr_grace_wait() skip secondary CPUs
until they have been started. However, this could break if the spinup
logic of secondary CPUs was changed.
Delayed SMR dispatch reported and fix tested by Hrvoje Popovski
Discussed with and OK kettenis@, claudio@
Diffstat (limited to 'sys/kern/init_main.c')
| -rw-r--r-- | sys/kern/init_main.c | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index 93e88828d2f..2be1d41b8ab 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -1,4 +1,4 @@ -/* $OpenBSD: init_main.c,v 1.295 2020/01/01 07:06:35 jsg Exp $ */ +/* $OpenBSD: init_main.c,v 1.296 2020/02/25 16:55:33 visa Exp $ */ /* $NetBSD: init_main.c,v 1.84.4.1 1996/06/02 09:08:06 mrg Exp $ */ /* @@ -551,6 +551,9 @@ main(void *framep) cpu_boot_secondary_processors(); #endif + /* Now that all CPUs partake in scheduling, start SMR thread. */ + smr_startup_thread(); + config_process_deferred_mountroot(); /* |