CVSROOT: /cvs
Module name: src
Changes by: d...@cvs.openbsd.org 2025/05/01 18:51:09
Modified files:
sys/kern : kern_timeout.c
Log message:
record which timeouts are running so timeout_barrier can do less work.
timeout_barrier (and timeout_del_barrier()) were naive and had to
assume that the specified timeout could be running, and therefore
unconditionally inserted a barrier task in the queue. however, it's
possible that timeouts weren't running, so timeout_barrier also had
to schedule the contexts that run the timeout queues to force the
barrier task to be completed quickly.
in practice timeout_barrier ended up generating a massive amount
of work to provide guarantees for something that's only true a tiny
(but critically important) fraction of the time. to mitigate this,
the queue runners now keep track of which timeout they're running
so timeout_barrier can check against it. if the specified timeout
is not running, then the barrier isn't necessary and timeout_barrier
can return early.
there is a chance that the check timeout_barrier does will produce
false positives if the timeout that produced the work that is running
has been recycled and now has timeout_barrier called against it.
the worst that will happen in this situation is we'll run the barrier
task for no benefit. however, that is far better than the current
situation where we schedule the barrier all the time and are now
suffering for it.
because timeout_barrier now knows if a context is running timeouts, it
no longer has to wake up or schedule the context to run the barrier. it
can assume it will be picked up because all these contexts loop until
they run out of work.
this also adds CIRCQ_INSERT_HEAD so we can put the barrier at the
top of the todo list and get it run sooner. this means the
timeout{_del}_barrier caller will wait less.
ok mpi@ mvs@ visa@
