From owner-freebsd-current Wed Sep 24 22:47:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27168 for current-outgoing; Wed, 24 Sep 1997 22:47:27 -0700 (PDT) Received: from lucifer.guardian.no (gate.guardian.no [195.1.254.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA27162 for ; Wed, 24 Sep 1997 22:47:20 -0700 (PDT) Received: (qmail 29669 invoked by uid 21574); 25 Sep 1997 05:47:14 -0000 Date: Thu, 25 Sep 1997 07:47:14 +0200 (MET DST) From: Finn Arne Gangstad To: "Justin T. Gibbs" cc: Archie Cobbs , current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <199709250512.XAA19962@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 24 Sep 1997, Justin T. Gibbs wrote: > >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. > > It looks like a 5 level hierarchical timing wheel to me. FreeBSD currently > has a one level timing wheel. Cascade_timers should enable interrupts > at deterministic intervals so that interrupts are defered a deterministic > amount of time. In 2.1.X it just grabs the timer spinlock. 2.0.X is pretty much set in stone really (the new timer code was actually put in in 2.1.23 i think, but applied to 2.0.30 for efficiency reasons). There was a lot of discussion on the kernel list about cascace_timers enabling timers now and then, in practice cascade_timers never move many timers so it's not really a problem, even less of a problem when it just grabs the timer lock. - Finn Arne