Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Nov 2006 14:58:23 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        John Baldwin <jhb@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: a proposed callout API
Message-ID:  <200611292258.kATMwNb6048849@apollo.backplane.com>
References:  <10814.1164829546@critter.freebsd.dk> <200611291650.51782.jhb@freebsd.org> <200611292243.kATMhmaY048753@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
   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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611292258.kATMwNb6048849>