From owner-freebsd-current Mon Sep 22 10:30:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01761 for current-outgoing; Mon, 22 Sep 1997 10:30:50 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01747 for ; Mon, 22 Sep 1997 10:30:45 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA21758; Mon, 22 Sep 1997 11:30:35 -0600 (MDT) Message-Id: <199709221730.LAA21758@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: gibbs@plutotech.com, current@FreeBSD.ORG, nate@mt.sri.com 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 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Tue, 23 Sep 1997 03:23:55 +1000." <199709221723.DAA23286@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 11:30:24 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>only 2 bits. This is 96 times denser than the current callout table. >> >>And runs in roughly O(n) time every time the interval timer expires. You > >No, it is O(1) in the usual case where the hardware has not timed out, >and O(n/32) (sic) otherwise (the bitmap can be scanned 32 bits at a time, >so 630 entries can be scanned in < 1us on a P5). Don't you have to look at each transaction when the interval timer goes off to see which, if any, of the transactions have expired? Remember that different transactions can have different timeout intervals. In the current SCSI system some tape operations have hour long timeouts while most disk activity is 10s, etc. >>also leave out the part about being able to index to transaction whose >>timer actually expired which will take additional space. > >Maybe. I know the drive number and the transaction number, and there's >presumably at worst a linked list of transactions attached to the drive >somehow (at best there's an array), and a linear search of this list >shouldn't take too long for an exceptional action. But it does take space. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================