apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: Observations on fragmentation in SMS pools
Date Tue, 10 Jul 2001 16:55:31 GMT
On 10 Jul 2001 16:57:25 +0200, Luke Kenneth Casson Leighton wrote:
> On Sun, Jul 08, 2001 at 10:19:33AM -0700, Justin Erenkrantz wrote:
> > On Sun, Jul 08, 2001 at 10:14:16AM -0700, dean gaudet wrote:
> > > an ideal situation for free-lists (blocks of freed, but not free()d
> > > memory) is one per cpu.
> > > 
> > > a less ideal situation is one per thread.
> > > 
> > > an even less ideal situation is one per process (which requires locking).
> > > 
> > > it's insane to have one per pool :)
> > 
> > I think we're shooting for #2 (less ideal).  Unless someone can come up
> > with a way to dynamically tell how many CPUs we are running on and bind
> > a free-list to a specific CPU.
> > 
> > We're currently doing #3 (even less ideal) in apr_pools.c.  
> > 
> > And, yeah, the current trivial SMS is doing #4.  =)  But, don't expect it 
> > to stay like that.  And, if we implement the apr_sms_child_malloc, it
> > gets to somewhere between #2 and #3.  -- justin
> 
> #5 the approach taken by tdb.  have a hash-chain.
> 
This is the approach the shared-mem hash I wrote is using...
If you can't get the tdb folks to see the BSD licence light, you
can always use that as a starting point.

> then you get the best of all worlds.  simultaneous access
> only requires that you lock *one* hash chain, which allows
> a theoretical limit of number-of-hash-bucket simultaneous
> accesses.
> 
> luke
> 
> p.s. i'm hoping that people will not be put off by tdb's GPL
> license because i think that there are some really good techniques
> used in there that could be applied to APR code, too.
--
Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608


Mime
View raw message