From owner-freebsd-arch Fri Aug 17 9:10:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 5CA1437B40D for ; Fri, 17 Aug 2001 09:10:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA23034; Fri, 17 Aug 2001 09:16:36 -0700 (PDT) Date: Fri, 17 Aug 2001 09:16:36 -0700 (PDT) From: Julian Elischer To: "Andrew R. Reiter" Cc: arch@freebsd.org Subject: Re: pool(9) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG so exactly how many kernel memory allocators do we need? zalloc, malloc, mbuf_alloc, kmem_alloc, bus_space_(mumble)_alloc, and now pool (shoulkd end in 'alloc :-) not to mention various private allocators, On Fri, 17 Aug 2001, Andrew R. Reiter wrote: > Hey, > > I was wondering if anyone had taken an interest in pool(9) from NetBSD -- > and now in OpenBSD. To explain what it is, I might as well quote a man > page (I know I'd mess it up ;-), a few more comments below it): > > DESCRIPTION > These utility routines provide management of pools of fixed-sized > areas of memory. Resource pools set aside an amount of memory for > exclusive use by the resource pool owner. This can be used by > applications to guarantee the availability of a minimum amount of memory > needed to continue operation independent of the memory resources currently > available from the system-wide memory allocator (malloc(9)). The pool manager > can optionally obtain temporary memory by calling the palloc() function > passed to pool_create(), for extra pool items in case the number of > allocations exceeds the nominal number of pool items managed by a pool > resource. This temporary memory will be automatically returned to the > system at a later time. > > -- > > I realize the state of -current and all that is going on, especially with > trying to get a 5.0 snap done by the end of the year, but I'd be > interested in seeing it in perhaps a later 5.x? Also, in that 5.x, I'd be > interested in seeing it actually being _used_ by certain kernel resources > -- perhaps VFS related things? If one is so inclined, grep for pool (or > it's functions) in the NetBSD and/or OpenBSD sys/kern director to see > where they are using it in there. > > Anyway, any interest in this? Sounds kind of nice, but perhaps we already > have a similar system in place that I am missing? > > Cheers, > > Andrew > > *-------------................................................. > | Andrew R. Reiter > | arr@fledge.watson.org > | "It requires a very unusual mind > | to undertake the analysis of the obvious" -- A.N. Whitehead > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message