From owner-freebsd-arch Fri Aug 17 9:28:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5D0CC37B40E for ; Fri, 17 Aug 2001 09:28:21 -0700 (PDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7HGSIn09786; Fri, 17 Aug 2001 12:28:18 -0400 (EDT) (envelope-from arr@watson.org) Date: Fri, 17 Aug 2001 12:28:18 -0400 (EDT) From: "Andrew R. Reiter" To: Julian Elischer 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 Good point. But, wouldn't it be nicer to have all those different _alloc's being part of a same interface known as pool? Please _smack_ me if Im wrong on this -- I take being wrong fairly well :-) cheers, andrew On Fri, 17 Aug 2001, Julian Elischer wrote: :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 :> : : *-------------................................................. | 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