Re: MemPools rewrite

On 19 Oct 2000, at 7:43, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Andres Kroonmaa wrote:
>
> > I don't think so. each separate malloc has its own memory overhead,
> > which is much smaller with memPools, especially for small object sizes.
> > For large objects you may be right, but direct reduction in overhead
> > is only part of the improvement.
>
> Preallocation would fix the initial fragmentation issue.

 If we need to preallocate a bunch every time to grow the pool, then why
 do that one object at a time, instead of allocating a chunk and splitting
 it internally? Why incur 16-byte overhead of libmalloc for each item of
 size int that is used in thousands? Squid has amasingly many allocations
 of size 4,8 bytes (even 1,2).

> > Because there are many Pools in separate memory areas, overall system
> > memory has quite different fragmentation issues. I hope to see better
> > fragmentation figures that would give most of the improvement.
>
> Fragmentation can be addressed without going to chunked allocation
> simply by allocating several entries at a time like Alex suggested, and
> then keep them relatively sorted and free from the "tail" (other end
> from where you are picking entries to use)

 For this we'd need to create all pools at the same time, and only once.
 After running for awhile system memory will be fragmented by zillions
 requests for URL strdups and frees, and next time you preallocate at a
 time, you won't get any similarity to chunked allocation. Individual
 object proximity will be absolutely random.
 Also, freeing from pool tail is only adding fuel to the fragmentation.

 I'm not talking about fragmentation in an hour or few of testloads, but
 of over weeks of operation under loads of 15K mallocs/frees per second.

 I don't believe that preallocation in bulk with current memPools will
 solve fragmentation.

 Basically, we might not reach ideal solution with chunked pools also,
 but Pool fragmentation and overhead can be accounted for in memory util
 page. I think this alone is already a useful feature. Currently we
 have some 50% of squid size in some shadow, unaccounted area.

> > btw, does "double" need to be aligned only on 64-bit cpus?
>
> double needs to be aligned to the alignment required by the CPU.
> Different for each, varying from 1 byte to 8 byte alignment if I
> remember correctly.

 I wonder what is meant by "needs" or "required" here. Will program
 brake miserably when alignment is not met, or is it just a matter
 of running slower? That is: how fatal is failing to align?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Thu Oct 19 2000 - 01:49:38 MDT