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 [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 364-8608
