What about a slab allocator
(e.g. http://www.cnds.jhu.edu/~jesus/418/SlabAllocator.pdf)
Joe
Bosko Milekic <[EMAIL PROTECTED]> wrote:
>
> On Thu, 29 Jun 2000, David Greenman wrote:
>
> > We used to do this in FreeBSD, but found that it was a bad idea for
> > performance reasons. Freeing and reallocating memory from the high-level
> > VM system is quite expensive and the trend in NICs these days is towards
> > needing the code to be even faster, not slower. Further, if the 'peak' is
> > reached often, then you're probably not really gaining much by freeing
> > the memory back to the common pool.
> >
> > -DG
>
> What was previously done at some point was use the kernel malloc() to
> allocate mbufs. As you know, this is a general purpose allocator that has
> to first determine what algorithm to use and then store the object
> correctly according to its size. This allocator is faster than that
> one. This allocator knows that it only has to deal with mbufs and knows
> that all of these mbufs are of the same size.
> I am not proposing to return to malloc(), I am proposing the new
> allocator.
> Also, the "peak" in this case is not reached often, obviously. It is
> designed with just that idea in mind. But, if the administrator feels
> that it is, I have provided the following mechanism:
>
> { jehovah:/home/bmilekic }>> sysctl -A | grep min_on_avail
> kern.ipc.min_on_avail: 0
>
> With this sysctl, the administrator can set a "minimum required" count
> for mbufs. In other words, it is possible to easily tell the system to
> keep as many mbufs as you'd like cached on the free lists.
>
> > David Greenman
> > Co-founder, The FreeBSD Project - http://www.freebsd.org
> > Manufacturer of high-performance Internet servers - http://www.terasolutions.com
> > Pave the road of life with opportunities.
>
> -Bosko
>
> --
> Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
> [EMAIL PROTECTED] * http://www.technokratis.com/
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
Joe McGuckin
ViaNet Communications
994 San Antonio Road
Palo Alto, CA 94303
Phone: 650-969-2203
Cell: 650-207-0372
Fax: 650-969-2124
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
