From owner-freebsd-current  Mon Sep 22 21:19:10 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA14209
          for current-outgoing; Mon, 22 Sep 1997 21:19:10 -0700 (PDT)
Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA14201
          for <current@FreeBSD.ORG>; Mon, 22 Sep 1997 21:19:07 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr08.primenet.com (8.8.5/8.8.5) id VAA07673;
	Mon, 22 Sep 1997 21:17:37 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199709230417.VAA07673@usr08.primenet.com>
Subject: Re: callouts in CAM (was Re: cvs commit:)
To: gibbs@plutotech.com (Justin T. Gibbs)
Date: Tue, 23 Sep 1997 04:17:37 +0000 (GMT)
Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com,
        bde@zeta.org.au, current@FreeBSD.ORG
In-Reply-To: <199709230245.UAA10200@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 08:45:12 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >You don't think it should be watermarked?  I am a fan of low watermark
> >based allocation scheduling (not necessarily immediate allocation, unless
> >the pool empties).  Mostly, I like this because the pools can be per
> >CPU, and thus you don't take a global resource lock in the SMP case.
> 
> My point is that clients can allocate or request for allocation
> deterministically as they know what their usage will be.  If there is an
> interface to do this, then the client can deal with a failure gracefully.
> If you rely on watermark based allocation and for some reason cannot keep
> up with demand, there is little you can do other than panic.

?

You stated before that you could simply block the request that would
have made use of a newly allocated resource until such time as one of
the existing entries becomes availble.  I'd hate to see max allocation
up front in all cases.  8-(.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.