From owner-freebsd-arch@FreeBSD.ORG Wed Nov 29 22:59:50 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F67C16A50D; Wed, 29 Nov 2006 22:59:50 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8B6443CBF; Wed, 29 Nov 2006 22:58:23 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.4) with ESMTP id kATMwNCL048850; Wed, 29 Nov 2006 14:58:27 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id kATMwNb6048849; Wed, 29 Nov 2006 14:58:23 -0800 (PST) Date: Wed, 29 Nov 2006 14:58:23 -0800 (PST) From: Matthew Dillon Message-Id: <200611292258.kATMwNb6048849@apollo.backplane.com> To: John Baldwin , Robert Watson , freebsd-arch@freebsd.org References: <10814.1164829546@critter.freebsd.dk> <200611291650.51782.jhb@freebsd.org> <200611292243.kATMhmaY048753@apollo.backplane.com> Cc: Subject: Re: a proposed callout API X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2006 22:59:50 -0000 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