![[BACK]](/icons/back.gif){kind=icon}
Up to [local] / src / sys / kern
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.16 / (download) - annotate - [select for diffs], Sun Aug 14 01:58:27 2022 UTC (21 months, 2 weeks ago) by jsg
Branch: MAIN
CVS Tags: OPENBSD_7_5_BASE,
OPENBSD_7_5,
OPENBSD_7_4_BASE,
OPENBSD_7_4,
OPENBSD_7_3_BASE,
OPENBSD_7_3,
OPENBSD_7_2_BASE,
OPENBSD_7_2,
HEAD
Changes since 1.15: +1 -2 lines
Diff to previous 1.15 (colored)
remove unneeded includes in sys/kern ok mpi@ miod@
Revision 1.15 / (download) - annotate - [select for diffs], Wed Nov 24 13:17:37 2021 UTC (2 years, 6 months ago) by visa
Branch: MAIN
CVS Tags: OPENBSD_7_1_BASE,
OPENBSD_7_1
Changes since 1.14: +2 -2 lines
Diff to previous 1.14 (colored)
Fix type of count.
Revision 1.14 / (download) - annotate - [select for diffs], Wed Nov 24 13:16:00 2021 UTC (2 years, 6 months ago) by visa
Branch: MAIN
Changes since 1.13: +9 -8 lines
Diff to previous 1.13 (colored)
Simplify arithmetics on the main path.
Revision 1.13 / (download) - annotate - [select for diffs], Wed Nov 24 09:47:49 2021 UTC (2 years, 6 months ago) by claudio
Branch: MAIN
Changes since 1.12: +16 -5 lines
Diff to previous 1.12 (colored)
Add a few dt(4) TRACEPOINTS to SMR. Should help to better understand what goes on in SMR. OK mpi@
Revision 1.12 / (download) - annotate - [select for diffs], Tue Jul 6 09:34:07 2021 UTC (2 years, 10 months ago) by kettenis
Branch: MAIN
CVS Tags: OPENBSD_7_0_BASE,
OPENBSD_7_0
Changes since 1.11: +3 -1 lines
Diff to previous 1.11 (colored)
Introduce CPU_IS_RUNNING() and us it in scheduler-related code to prevent waiting on CPUs that didn't spin up. This will allow us to spin down CPUs in the future to save power as well. ok mpi@
Revision 1.11 / (download) - annotate - [select for diffs], Tue Jun 29 21:31:49 2021 UTC (2 years, 11 months ago) by kettenis
Branch: MAIN
Changes since 1.10: +1 -3 lines
Diff to previous 1.10 (colored)
Didn't intend to commit the CPU_IS_RUNNING() changes just yet, so revert those bits.
Revision 1.10 / (download) - annotate - [select for diffs], Tue Jun 29 21:27:53 2021 UTC (2 years, 11 months ago) by kettenis
Branch: MAIN
Changes since 1.9: +3 -1 lines
Diff to previous 1.9 (colored)
SMP support. Mostly works, but occasionally craps out during boot. ok drahn@
Revision 1.9 / (download) - annotate - [select for diffs], Fri Dec 25 12:49:31 2020 UTC (3 years, 5 months ago) by visa
Branch: MAIN
CVS Tags: OPENBSD_6_9_BASE,
OPENBSD_6_9
Changes since 1.8: +26 -6 lines
Diff to previous 1.8 (colored)
Small smr_grace_wait() optimization Make the SMR thread maintain an explicit system-wide grace period and make CPUs observe the current grace period when crossing a quiescent state. This lets the SMR thread avoid a forced context switch for CPUs that have already entered the latest grace period. This change provides a small improvement in smr_grace_wait()'s performance in terms of context switching. OK mpi@, anton@
Revision 1.8 / (download) - annotate - [select for diffs], Fri Apr 3 03:36:56 2020 UTC (4 years, 2 months ago) by visa
Branch: MAIN
CVS Tags: OPENBSD_6_8_BASE,
OPENBSD_6_8,
OPENBSD_6_7_BASE,
OPENBSD_6_7
Changes since 1.7: +1 -23 lines
Diff to previous 1.7 (colored)
Adjust SMR_ASSERT_CRITICAL() and SMR_ASSERT_NONCRITICAL() so that the panic message shows the actual code location of the assert. Do this by moving the assert logic inside the macros. Prompted by and OK claudio@ OK mpi@
Revision 1.7 / (download) - annotate - [select for diffs], Tue Feb 25 16:55:33 2020 UTC (4 years, 3 months ago) by visa
Branch: MAIN
Changes since 1.6: +3 -5 lines
Diff to previous 1.6 (colored)
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@
Revision 1.6 / (download) - annotate - [select for diffs], Mon Dec 30 23:56:26 2019 UTC (4 years, 5 months ago) by jsg
Branch: MAIN
Changes since 1.5: +3 -3 lines
Diff to previous 1.5 (colored)
convert infinite msleep(9) to msleep_nsec(9) ok mpi@
Revision 1.5 / (download) - annotate - [select for diffs], Wed Jul 3 22:39:33 2019 UTC (4 years, 11 months ago) by cheloha
Branch: MAIN
CVS Tags: OPENBSD_6_6_BASE,
OPENBSD_6_6
Changes since 1.4: +3 -3 lines
Diff to previous 1.4 (colored)
Add tsleep_nsec(9), msleep_nsec(9), and rwsleep_nsec(9). Equivalent to their unsuffixed counterparts except that (a) they take a timeout in terms of nanoseconds, and (b) INFSLP, aka UINT64_MAX (not zero) indicates that a timeout should not be set. For now, zero nanoseconds is not a strictly valid invocation: we log a warning on DIAGNOSTIC kernels if we see such a call. We still sleep until the next tick in such a case, however. In the future this could become some sort of poll... TBD. To facilitate conversions to these interfaces: add inline conversion functions to sys/time.h for turning your timeout into nanoseconds. Also do a few easy conversions for warmup and to demonstrate how further conversions should be done. Lots of input from mpi@ and ratchov@. Additional input from tedu@, deraadt@, mortimer@, millert@, and claudio@. Partly inspired by FreeBSD r247787. positive feedback from deraadt@, ok mpi@
Revision 1.4 / (download) - annotate - [select for diffs], Fri May 17 03:53:08 2019 UTC (5 years ago) by visa
Branch: MAIN
Changes since 1.3: +1 -4 lines
Diff to previous 1.3 (colored)
Add SMR_ASSERT_NONCRITICAL() in assertwaitok(). This eases debugging because now the error is detected before context switch. The sleep code path eventually calls assertwaitok() in mi_switch(), so the assertwaitok() in the SMR barrier function is somewhat redundant and can be removed. OK mpi@
Revision 1.3 / (download) - annotate - [select for diffs], Thu May 16 13:52:47 2019 UTC (5 years ago) by visa
Branch: MAIN
Changes since 1.2: +3 -21 lines
Diff to previous 1.2 (colored)
Remove incorrect optimization. The current logic for skipping idle CPUs does not establish strong enough ordering between CPUs. Consequently, smr_grace_wait() might incorrectly skip a CPU and invoke an SMR callback too early. Prompted by haesbaert@
Revision 1.2 / (download) - annotate - [select for diffs], Tue May 14 03:27:43 2019 UTC (5 years ago) by visa
Branch: MAIN
Changes since 1.1: +22 -1 lines
Diff to previous 1.1 (colored)
Add lock order checking for smr_barrier(9). This is similar to the checking done in taskq_barrier(9) and timeout_barrier(9). OK mpi@
Revision 1.1 / (download) - annotate - [select for diffs], Tue Feb 26 14:24:21 2019 UTC (5 years, 3 months ago) by visa
Branch: MAIN
CVS Tags: OPENBSD_6_5_BASE,
OPENBSD_6_5
Introduce safe memory reclamation, a mechanism for reclaiming shared objects that readers can access without locking. This provides a basis for read-copy-update operations. Readers access SMR-protected shared objects inside SMR read-side critical section where sleeping is not allowed. To reclaim an SMR-protected object, the writer has to ensure mutual exclusion of other writers, remove the object's shared reference and wait until read-side references cannot exist any longer. As an alternative to waiting, the writer can schedule a callback that gets invoked when reclamation is safe. The mechanism relies on CPU quiescent states to determine when an SMR-protected object is ready for reclamation. The <sys/smr.h> header additionally provides an implementation of singly- and doubly-linked lists that can be used together with SMR. These lists allow lockless read access with a concurrent writer. Discussed with many OK mpi@ sashan@