wireguard-openbsd/sys/kern/kern_clock.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/kern_clock.c?h=jd%2Fqueueboosts 2020-01-21T16:16:22Z Import dt(4) a driver and framework for Dynamic Profiling. 2020-01-21T16:16:22Z mpi mpi@openbsd.org 2020-01-21T16:16:22Z urn:sha1:91b2ecf67e2a667ccefd071f95f44a8068f1bbc4 The design is fairly simple: events, in the form of descriptors on a ring, are being produced in any kernel context and being consumed by a userland process reading /dev/dt. Code and hooks are all guarded under '#if NDT > 0' so this commit shouldn't introduce any change as long as dt(4) is disable in GENERIC. ok kettenis@, visa@, jasper@, deraadt@ softclock: move softintr registration/scheduling into timeout module 2019-11-02T16:56:17Z cheloha cheloha@openbsd.org 2019-11-02T16:56:17Z urn:sha1:8fe879fb5c20bee4c0ed88c65c92e69c6daf7d31 softclock() is scheduled from hardclock(9) because long ago callouts were processed from hardclock(9) directly. The introduction of timeout(9) circa 2000 moved all callout processing into a dedicated module, but the softclock scheduling stayed behind in hardclock(9). We can move all the softclock() "stuff" into the timeout module to make kern_clock.c a bit cleaner. Neither initclocks() nor hardclock(9) need to "know" about softclock(). The initial softclock() softintr registration can be done from timeout_proc_init() and softclock() can be scheduled from timeout_hardclock_update(). ok visa@ per-process itimers: itimerval -> itimerspec 2019-08-02T02:17:35Z cheloha cheloha@openbsd.org 2019-08-02T02:17:35Z urn:sha1:fcfbe7d9ad2cb0aec6d1e247491923311676b7b2 Loongson runs at 128hz. 128 doesn't divide evenly into a million, but it does divide evenly into a billion. So if we do the per-process itimer bookkeeping with itimerspec structs we can have error-free virtual itimers on loongson just as we do on most other platforms. This change doesn't fix the virtual itimer error alpha, as 1024 does not divide evenly into a billion. But this doesn't make the situation any worse, either. ok deraadt@ Simplify by using `spc' since we already have it, no behavior change. 2019-01-28T11:49:04Z mpi mpi@openbsd.org 2019-01-28T11:49:04Z urn:sha1:100aa75baf5ff72745afbaef2314713978ebbcad Only the scheduler time statistics should be affected by spinning. 2018-10-17T12:25:38Z bluhm bluhm@openbsd.org 2018-10-17T12:25:38Z urn:sha1:4667466ef80c558d50be8ee6cf5ab029e11afb65 Change the process time accounting back to the original code before spinning time was added. No change for scheduler time. Spinning interrupts are no longer accounted to process system time. input and OK visa@ User land time accounting has changed when kernel spinning time was 2018-10-10T00:04:54Z bluhm bluhm@openbsd.org 2018-10-10T00:04:54Z urn:sha1:33815e14fd112b99d415269c7f3e1941157b74c3 introduced. Account spinning time to the process system time again. time(1) has no spinning, it only shows real, user, sys. OK visa@ mpi@ deraadt@ drop BUMPTIME 2018-06-04T18:16:43Z cheloha cheloha@openbsd.org 2018-06-04T18:16:43Z urn:sha1:a97de0f1be611f50902aad4286da83e37fcd797a unused since v1.76, ca 5.3 ok kettenis@ deraadt@ Stopping counting and reporting CPU time spent spinning on a lock as 2018-05-14T12:31:21Z mpi mpi@openbsd.org 2018-05-14T12:31:21Z urn:sha1:531d8034253fb82282f0f353c086e9ad827e031c system time. Introduce a new CP_SPIN "scheduler state" and modify userland tools to display the % of timer a CPU spents spinning. Based on a diff from jmatthew@, ok pirofti@, bluhm@, visa@, deraadt@ Introduce jiffies, a volatile unsigned long version of our ticks variable 2017-07-22T14:33:45Z kettenis kettenis@openbsd.org 2017-07-22T14:33:45Z urn:sha1:ebbbc3a6cf6b55a12c8e3a415ac3de213e07668e for use by the linux compatibility APIs in drm(4). While I hate infecting code in sys/kern with this, untangling all the of having different types and different signedness is too much for me right now. The best strategy may be to change ticks itself to be long but that needs some careful auditing. ok deraadt@ clear structure on the stack before copying out for sysctl. At present 2017-04-05T03:59:13Z deraadt deraadt@openbsd.org 2017-04-05T03:59:13Z urn:sha1:83201e26d4d23a5820fad729af13791adb0207ae it has no pads, but a future ABI change could add something and leak kernel memory.