apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject RE: SMS usage patterns, hierarchies
Date Wed, 11 Jul 2001 17:01:30 GMT
On Wed, 11 Jul 2001, Sander Striker wrote:

> > Thanks.  If I'm reading the graphs right, they show
> > that destruction of a leaf SMS with siblings is much
> > more common than destruction or reset of a non-leaf
> > SMS with children.  That seems to reinforce the
> > conclusion I drew from gprof data: we could get better
> > performance by allocating blocks for a child from
> > something that isn't the direct parent (like a per-CPU
> > free list, based on Dean's recommendation).
> I want to discuss this some more to be honest.  There
> are several options we can try and I feel it is best
> to examine more than one, even though one looks like
> the way to go.  A per-CPU free list will be difficult
> to implement for reasons Justin pointed out.
> A per thread free list is a lot easier.  Actually, if
> we use an sms like "tracking" instead of "trivial" we get
> one free list.  If we then use the "threads" sms (which
> I should commit (I'll wait until Davids patch is in))
> as the parent sms of all the top level smss in each
> thread, we get a free list per thread.  But, this
> requires tweaking httpd, which right now is not really
> an option.

if you use malloc/free directly (for blocks, not for each palloc) and have
no free list then on linux the ptmalloc built into libc will do per-cpu
free listing for you.  similarly on solaris with the shipped mtmalloc
library.  and on either of those platforms with the hoard library.

this is only critical on large multicpu boxes... which right now, the
majority of the market in that area is solaris.  and fwiw, linux is alive
and well in the multi-cpu area -- SGI has ditched IRIX in favour of linux,
and IBM has a large linux initiative, but still has AIX on the side-line
'cause IBM never gets rid of an operating system.

i'm not sure the *BSDs have made it very far past the "big kernel lock"
type of multiprocessing yet, and so i'm not sure how well they scale at
the kernel level on large multiprocessors.  reports to the contrary

i know nothing about the quality of windows malloc on multi-cpu boxes.
if you look at the link i sent a couple days ago
<http://soldc.sun.com/articles/multiproc/multiproc.html>, there are
several tools for testing the scalability of malloc.

so what i've been advocating is to get rid of the free lists and leave it
up to the vendors (or a malloc replacement library) to do the right thing.


View raw message