From owner-freebsd-current  Wed Sep 24 21:51:18 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA24735
          for current-outgoing; Wed, 24 Sep 1997 21:51:18 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA24725
          for <current@FreeBSD.ORG>; Wed, 24 Sep 1997 21:51:12 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id VAA26747;
	Wed, 24 Sep 1997 21:50:05 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd026739; Thu Sep 25 04:50:02 1997
Date: Wed, 24 Sep 1997 21:49:11 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Finn Arne Gangstad <finnag@guardian.no>
cc: Archie Cobbs <archie@whistle.com>, current@FreeBSD.ORG
Subject: Re: timeout management (was: Re: cvs commit: ...)
In-Reply-To: <Pine.LNX.3.95.970925053231.28877A-100000@lucifer.guardian.no>
Message-ID: <Pine.BSF.3.95.970924214735.12006C-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > 
> 
> Have you guys looked at the timer code in Linux? It basically is a small
> variation of this, which makes all operations  O(1) for almost
> every timer.
> 
> The idea is that instead of splitting each range into 2, you split each
> range into 256 (for the first range) and 32 for all other ranges.
> 
> Most timers will be less than 256 ticks into the future, so they will
> never be moved, and 99% of the rest will in the 32 * 256 ticks range, and
> will, if they are not cancelled (which around 90% seem to be), only be
> moved once. 
> 
> It's in kernel/sched.c if you're unfamiliar with Linux :)

the first set of 256 is similar to the new system in FreeBSD
The second one could be sonsidered as similar, but just
repeated.
> 
> - Finn Arne
> 
>