Date: Mon, 22 Sep 1997 11:30:24 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Bruce Evans <bde@zeta.org.au> 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 ... Message-ID: <199709221730.LAA21758@pluto.plutotech.com> In-Reply-To: Your message of "Tue, 23 Sep 1997 03:23:55 %2B1000." <199709221723.DAA23286@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>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 ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221730.LAA21758>