Date: Fri, 17 Aug 2001 12:28:18 -0400 (EDT) From: "Andrew R. Reiter" <arr@watson.org> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: pool(9) Message-ID: <Pine.NEB.3.96L.1010817122717.9776A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0108170914530.22899-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010817122717.9776A-100000>