From owner-freebsd-current Mon Sep 22 12:32:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11969 for current-outgoing; Mon, 22 Sep 1997 12:32:36 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11961 for ; Mon, 22 Sep 1997 12:32:31 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14648; Mon, 22 Sep 1997 13:32:20 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02277; Mon, 22 Sep 1997 13:32:20 -0600 (MDT) Date: Mon, 22 Sep 1997 13:32:20 -0600 (MDT) Message-Id: <199709221932.NAA02277@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-Reply-To: <199709221926.MAA16814@usr06.primenet.com> References: <199709221559.JAA17865@pluto.plutotech.com> <199709221926.MAA16814@usr06.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >A more deterministic implementation would associate an absolute tick > > >value (rather than a count) with each entry, and insert entries in > > >sorted order. > > > > More deterministic for who? This trades O(1) insertion for O(hash chain > > length) insertion so that softclock will become O(timeouts for the current > > tick). As timeout often is called from an interrupt context > > it is not so clear where it is better to pay the price of non-determinism. > > I'm not so sure timeouts should be called from an interrupt context, > ever. [ rest deleted ] We're talking reality here Terry, not theory. 'If the world were a perfect place, we wouldn't need interrupts since we could get everything done when we needed to and it wouldn't mess with anything else, but this isn't a perfect world.' The extra complexity required to do your above solution is *WAY* overkill. (I've done things such as it on a small-scale basis, and performance starts to drop off quickly due to data synchronization when you have lots of 'objects/drivers'.) Nate