apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject Re: Observations on fragmentation in SMS pools
Date Sun, 08 Jul 2001 18:47:02 GMT
On Sun, 8 Jul 2001, Brian Pane wrote:

> dean gaudet wrote:
> >On Sun, 8 Jul 2001, Ian Holsman wrote:
> >
> >>dean gaudet wrote:
> >>
> >>>it removes block_freelist and uses malloc/free for blocks.  this is much
> >>>less expensive than malloc/free on each allocation (amortization).
> >>>
> >>If you can wait till monday, and you are interested, I'll put it through
> >>the ringer on a 8-CPU Sun4500
> >>
> >
> >oh i'm in no rush, i'm being a lazy ass and not even testing these things
> >i'm posting, so thanks for helping :)  also, you would definitely want to
> >try the www.hoard.org allocator on a (solaris) machine with that many
> >cpus.
> >
> If I remember correctly, he's tried the Hoard allocator on
> a server that size with ALLOC_USE_MALLOC, and it performed
> much better than the global free list.  But Hoard is LGPL. :-(

i would totally believe that the ALLOC_USE_MALLOC code performs better
with hoard on a server that size... because the ALLOC_USE_MALLOC code
doesn't need to use a mutex ever.  the global freelist stuff is just a bad
idea on a box with 8 cpus, the mutex kills ya.

but with the elimination of the mutex we should scale better even just
using regular malloc.

i wasn't advocating bundling hoard, it's firmly my opinion that each libc
vendor should be doing their damndest to provide the best malloc possible.
(especially because each libc vendor tends to also be a libpthread vendor
and they know the dirty details of making the two work well together).
i've no qualms with putting "try hoard" into the "how do i perf tune
apache?" page.  it wouldn't be a requirement...


View raw message