From owner-freebsd-current Mon Sep 22 12:07:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09935 for current-outgoing; Mon, 22 Sep 1997 12:07:27 -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 MAA09928 for ; Mon, 22 Sep 1997 12:07:22 -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 NAA14452; Mon, 22 Sep 1997 13:05:29 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02100; Mon, 22 Sep 1997 13:05:28 -0600 (MDT) Date: Mon, 22 Sep 1997 13:05:28 -0600 (MDT) Message-Id: <199709221905.NAA02100@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Terry Lambert , 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: <199709221559.JAA17865@pluto.plutotech.com> References: <199709220647.XAA16869@usr07.primenet.com> <199709221559.JAA17865@pluto.plutotech.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. > Softclock has the luxury of lowering it's spl at deterministic intervals > (see the implementation) while a caller from an interrupt context doesn't. > the current implementation always blocks interrupts for a deterministic > amount of time. What you propose doesn't. >From reading the papers, the performance would be neglidgable (sp?) since they assume the hash chain length is <= 1. That's one of the performance gains they assume. > Even so, it is probably better to store an absolute tick value regardless > so that you don't have to perform the subtraction. A substraction is *dirt cheap* to do. Finding the element on the list is much more expensive than the subtraction. Nate