Date: Tue, 23 Sep 1997 04:17:37 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: callouts in CAM (was Re: cvs commit:) Message-ID: <199709230417.VAA07673@usr08.primenet.com> In-Reply-To: <199709230245.UAA10200@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 08:45:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709230417.VAA07673>