From owner-freebsd-current Mon Sep 22 23:34:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22886 for current-outgoing; Mon, 22 Sep 1997 23:34:56 -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 XAA22877 for ; Mon, 22 Sep 1997 23:34:52 -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 AAA13555; Tue, 23 Sep 1997 00:34:43 -0600 (MDT) Message-Id: <199709230634.AAA13555@pluto.plutotech.com> To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.org Subject: Re: callouts in CAM (was Re: cvs commit:) In-reply-to: Your message of "Tue, 23 Sep 1997 04:17:37 -0000." <199709230417.VAA07673@usr08.primenet.com> Date: Tue, 23 Sep 1997 00:34:32 -0600 From: "Justin T. Gibbs" 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-(. New work comes in. There are no CCBs/callouts available in the free pool. An attempt is made to allocate a CCB and it's corresponding callout. If that fails (malloc failure), I wait for an existing CCB/callout to come free. Where does this contradict what I said above? Where is the max allocation up front? I allocate on demand. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================