Re: chunked MemPool

On 17 Apr 2001, at 17:33, Adrian Chadd <adrian@creative.net.au> wrote:

> On Tue, Apr 17, 2001, Andres Kroonmaa wrote:
>
> > There are only very few pools that would benefit from trees - mainly
> > storeEntry, MD5, and LRU pools. And these are generally very longlived
> > object, being freed quite rarely, so overhead of plain search is quite
> > small on average.
>
> Have you tried it yet?

 You mean tree search? no.
 If I knew which tree code to try I'd try it. I think Henrik meant some
 tree code not used in squid, and I hope he'll point me at one.
 I have about zero experience with any trees...

 From what I've read I understand that to have benefit from trees we'd
 need a well balanced tree which is quite a challenge. splay seems to
 give good results on average, but still can occasionally require a
 full search.

> I'll go and profile/bugcheck the chunked mempool branch to see if
> its stable enough to hit 2.5. I'll then go hit the net for some
> research papers covering memory allocators, and see how this
> could be made faster. We're _going_ to need a fast memory allocator,
> and we're going to have to cut down on the number of allocations
> made in the request path to bump down the CPU requirements..

 hmm. fast and conservative are usually exclusive ;)
 Most of the cpu time goes to mempool statistics gathering anyway...
 If we can drop stats, then we could place all frees into single
 linklist cache and have nearzero alloc/free overhead, and then
 handle the chunks only when actually need to free one.
 Zeroing of freed object is also cpu-hog, especially for large
 objects where zeroing is least needed. Do we need zeroing for
 buffers? Perhaps skip that for objects with sizes multiples of
 pagesize? Or add some flags to pools.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Apr 17 2001 - 10:04:49 MDT