wireguard-openbsd/sys/kern/kern_timeout.c, branch jd/queueboosts

Cleanup and includes.

2020-02-18T12:13:39Z

Do not include where it is not needed and stop including in it. ok visa@, anton@

Raise ipl of the softclock thread to IPL_SOFTCLOCK.

2020-01-13T09:51:52Z

This prevent the soft-interrupt to run in-between of timeouts executed in a thread context. ok kettenis@, visa@

timeout(9): delay thread wakeup(9) decision to end of softclock() loop

2020-01-03T20:11:11Z

The process-context timeout(s) in question might be cancelled before we leave the loop, leading to a spurious wakeup(9). ok mpi@

timeout(9): Add timeout_set_flags(9) and TIMEOUT_INITIALIZER_FLAGS(9)

2020-01-03T02:16:38Z

These allow the caller to initialize timeouts with arbitrary flags. We only have one flag at the moment, TIMEOUT_PROC, but experimenting with other flags is easier if these interfaces are available in-tree. With input from bluhm@, guenther@, and visa@. "makes sense to me" bluhm@, ok visa@

timeout(9): Rename the TIMEOUT_NEEDPROCCTX flag to TIMEOUT_PROC.

2020-01-03T01:16:12Z

This makes it more likely to fit into 80 columns if used alongside the forthcoming timeout_set_flags() and TIMEOUT_INITIALIZER_FLAGS() interfaces. "makes sense to me" bluhm@, ok visa@

timeout(9): new flag: TIMEOUT_SCHEDULED, new statistic: tos_scheduled

2019-12-25T00:15:36Z

This flag is set whenever a timeout is put on the wheel and cleared upon (a) running, (b) deletion, and (c) readdition. It serves two purposes: 1. Facilitate distinguishing scheduled and rescheduled timeouts. When a timeout is put on the wheel it is "scheduled" for a later softclock(). If this happens two or more times it is also said to be "rescheduled". The tos_rescheduled value thus indicates how many distant timeouts have been cascaded into a lower wheel level. 2. Eliminate false late timeouts. A timeout is not late if it is due before softclock() has had a chance to schedule it. To track this we need additional state, hence a new flag. rprocter@ raises some interesting questions. Some answers: - This interface is not stable and name changes are possible at a later date. - Although rescheduling timeouts is a side effect of the underlying implementation, I don't forsee us using anything but a timeout wheel in the future. Other data structures are too slow in practice, so I doubt that the concept of a rescheduled timeout will be irrelevant any time soon. - I think the development utility of gathering these sorts of statistics is high. Watching the distribution of timeouts under a given workflow is informative. ok visa@

Recommit "timeout(9): make CIRCQ look more like other sys/queue.h data structures"

2019-12-12T18:12:43Z

Backed out during revert of "timeout(9): switch to tickless backend". Original commit message: - CIRCQ_APPEND -> CIRCQ_CONCAT - Flip argument order of CIRCQ_INSERT to match e.g. TAILQ_INSERT_TAIL - CIRCQ_INSERT -> CIRCQ_INSERT_TAIL - Add CIRCQ_FOREACH, use it in ddb(4) when printing buckets - While here, use tabs for indentation like we do with other macros ok visa@ mpi@

Revert "timeout(9): switch to tickless backend"

2019-12-02T21:47:54Z

It appears to have caused major performance regressions all over the network stack. Reported by bluhm@ ok deraadt@

timeout(9): make CIRCQ look more like other sys/queue.h data structures

2019-11-29T12:50:48Z

- CIRCQ_APPEND -> CIRCQ_CONCAT - Flip argument order of CIRCQ_INSERT to match e.g. TAILQ_INSERT_TAIL - CIRCQ_INSERT -> CIRCQ_INSERT_TAIL - Add CIRCQ_FOREACH, use it in ddb(4) when printing buckets - While here, use tabs for indentation like we do with other macros ok visa@

timeout(9): switch to tickless backend

2019-11-26T15:27:08Z

Rebase the timeout wheel on the system uptime clock. Timeouts are now set to run at or after an absolute time as returned by nanouptime(9). Timeouts are thus "tickless": they expire at a real time on that clock instead of at a particular value of the global "ticks" variable. To facilitate this change the timeout struct's .to_time member becomes a timespec. Hashing timeouts into a bucket on the wheel changes slightly: we build a 32-bit hash with 25 bits of seconds (.tv_sec) and 7 bits of subseconds (.tv_nsec). 7 bits of subseconds means the width of the lowest wheel level is now 2 seconds on all platforms and each bucket in that lowest level corresponds to 1/128 seconds on the uptime clock. These values were chosen to closely align with the current 100hz hardclock(9) typical on almost all of our platforms. At 100hz a bucket is currently ~1/100 seconds wide on the lowest level and the lowest level itself is ~2.56 seconds wide. Not a huge change, but a change nonetheless. Because a bucket no longer corresponds to a single tick more than one bucket may be dumped during an average timeout_hardclock_update() call. On 100hz platforms you now dump ~2 buckets. On 64hz machines (sh) you dump ~4 buckets. On 1024hz machines (alpha) you dump only 1 bucket, but you are doing extra work in softclock() to reschedule timeouts that aren't due yet. To avoid changing current behavior all timeout_add*(9) interfaces convert their timeout interval into ticks, compute an equivalent timespec interval, and then add that interval to the timestamp of the most recent timeout_hardclock_update() call to determine an absolute deadline. So all current timeouts still "use" ticks, but the ticks are faked in the timeout layer. A new interface, timeout_at_ts(9), is introduced here to bypass this backwardly compatible behavior. It will be used in subsequent diffs to add absolute timeout support for userland and to clean up some of the messier parts of kernel timekeeping, especially at the syscall layer. Because timeouts are based against the uptime clock they are subject to NTP adjustment via adjtime(2) and adjfreq(2). Unless you have a crazy adjfreq(2) adjustment set this will not change the expiration behavior of your timeouts. Tons of design feedback from mpi@, visa@, guenther@, and kettenis@. Additional amd64 testing from anton@ and visa@. Octeon testing from visa@. macppc testing from me. Positive feedback from deraadt@, ok visa@