Andres Kroonmaa wrote:
> heap_node. I modified dlmalloc abit so that it was eager to alloc
> chunks with mmap(). So unfilled chunks didn't contribute to heap
> fragmentation. Of course, dlmalloc wastes 1 page per mmapped alloc,
> so memory benefits were with larger chunks. While chasing the
well... dlmalloc uses a small 16 bytes (or was it 8) header on each
mmap() area, so if you round down your allocations by this amount there
should be no waste of pages.
> It is hard to tell what pools get the least. Perhaps those that
> only make very few allocations during a squid run, and I picked
> minimal chunk size to be 16K. Some pools stayed empty most of the
> time.
Yes. And as the number of pools are growing a lot in 2.5 with lots of
small pools we probably want to decrease the lower limit to only a few
kb.
> cpu overhead is quite minimal. Mostly is during a free, as we
> have to find a chunk where the obj belongs. The more chunks in
> a pool, the more overhead. But in terms of CPU ticks it wasn't
> bad at all. I also zero out freed objects, and this takes on
> average more time than finding a chunk. Basically, CPU times
> were comparable to old mempool very closely.
And hashes or similar "chunk indexes" can be used to reduce the
searching considerably.
> Added complexity is transparent, and not extremely high.
Shouldn't be.
Do you mind putting this improved mempool up on SourceForge to ease
further development and testing until merged into HEAD?
/Henrik
Received on Fri Mar 30 2001 - 03:48:59 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:41 MST