From owner-freebsd-current Mon Sep 22 08:02:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17623 for current-outgoing; Mon, 22 Sep 1997 08:02:05 -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 IAA17616 for ; Mon, 22 Sep 1997 08:02:01 -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 JAA16510; Mon, 22 Sep 1997 09:01:46 -0600 (MDT) Message-Id: <199709221501.JAA16510@pluto.plutotech.com> 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 00:40:34 +1000." <199709221440.AAA18001@godzilla.zeta.org.au> Date: Mon, 22 Sep 1997 09:01:36 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>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. > >This one is: when attaching a drive, find a free drive number and malloc >more storage if the new number is at the end. How much storage do I need in order to realloc the arrays? Is it bounded? The current implementation only needs to allocate a callout at a time if it wants to grow the number of callouts. It may, in fact be nice to add an interface for clients to add additional callouts if they are heavy users of them. For instance, the CAM system grows it's number of transactions dynamically and will simply stop growing if it can't malloc more. In your scenario, if you can't allocate space for a drive and it's transactions, you can't talk to the drive. >The main point is that it is easy to build a perfect hash function >(drive_number, transaction_number) -> timeout_slot_number because we >only need one timeout per (drive_number, transaction_number). I thought your point was that every client should make up their own solution to this problem instead of making the generic solution more efficient. 8-) >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================