From owner-freebsd-current  Mon Sep 22 10:37:23 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA02550
          for current-outgoing; Mon, 22 Sep 1997 10:37:23 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA02538
          for <current@FreeBSD.ORG>; Mon, 22 Sep 1997 10:37:18 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id KAA02955;
	Mon, 22 Sep 1997 10:01:29 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd002951; Mon Sep 22 17:01:28 1997
Message-ID: <3426AA40.41C67EA6@whistle.com>
Date: Mon, 22 Sep 1997 10:26:24 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: "Justin T. Gibbs" <gibbs@plutotech.com>
CC: Bruce Evans <bde@zeta.org.au>, 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 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 a
References: <199709221347.HAA15157@pluto.plutotech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Justin T. Gibbs wrote:

The thing I don't like abut what has been done is:

It's changed a very standard and well understood service in the kernel.
I think you should have left it the same and implimented a cam_timeout
facility that runs separatly.

all my drivers that are shared between various OS now need to 
be modified, with a new #if defined(__FreeBSD__) in them.


> 
> >>Take a server with 10 Seagate disks.  Each one of these disks can
> >>handle 63 transactions at a time.  If you split the disks across
> >>controllers correctly, you can readily keep them saturated with
> >>requests.  Thats 630 pending callouts and an O(n) hit for insert
> >>and removal...
> >
> >Assuming that the timeout length is not very critical, and that timeouts
> >rarely expire, this setup could be optimized well using "queues"
> >consisting of two (pointers to) arrays of bits, and counters for the
> >number of items set in each array:
> 
> Now make it scale during usage.  There are lots of schemes available,
> but very few are easily scalable by mallocing small chunks of free
> memory.
> 
> >Bruce
> 
> --
> Justin T. Gibbs
> ===========================================
>   FreeBSD: Turning PCs into workstations
> ===========================================