a proposed callout API
Matthew Dillon
dillon at apollo.backplane.com
Wed Nov 29 14:59:50 PST 2006
Oh, one more note on why passing a tick_t to the callback procedure is
the better way to go when operating with fine-grained timeouts.
Consider aggregation. Lets say you are using a fine-grained periodic
timer for your scheduler clock at, say, 1000hz, and a different
fine-grained periodic timer for your network poll at, say, 1000hz.
If both timers are installed at the same time and use the same initial
deadline timestamp, then both timeouts will occur at the same time.
If the deadline is passed as an argument to the callout (not the actual
current timestamp, but the deadline that was recorded, even if the event
is somewhat late), then a periodic reload based on that passed timestamp
will STAY SYNCHRONIZED for both events, even though they are
'independant'.
The importance of this cannot be underestimated because it removes
all extra hardware interrupts that would otherwise occur if the
separately timed periodic events were not synchronized with each other.
Similarly, if you have any set of periodic operations whos events share
common factors, then some of those events will occur at the same time.
The result is *significantly* more optimal hardware timer interrupts
and timer callback event processing. And I do mean significant.
--
To put it another way, if you have two independant subsystems each
operating at 1000hz, would you rather take 1000 interrupts per second
or 2000 interrupts per second? The answer should be clear. This
really makes the case for passing deadlines instead of relative ticks.
In DragonFly I mentioned that we have per-cpu SYSTIMERs, but we are
still using the 8254 (instead of the LAPIC) to drive them. Each cpu
gets its own scheduler clock, stats clock, and so on and so forth. Each
one. The events can multiply very quickly, but because all the periodic
requests are synchronized with each other and run at either the same
frequency or have common divisors or multiples, the actual hardware
clock interrupt rate is bounded. This has turned out to be so important
that I am seriously considering creating an initial synchronization
calculation when installing a periodic timer to try to sync it up with
other periodic timers running on the system.
-Matt
More information about the freebsd-arch
mailing list