Re: MemPools rewrite

On 18 Oct 2000, at 15:12, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> On Wed, 18 Oct 2000, Andres Kroonmaa wrote:
>
> > seems that I've missed that train. Why was it killed?
>
> You cannot miss the train that never showed up :). As I said, the
> initial code was never released. IIRC, the reasons I decided to kill the
> initial design were:
>
> - no hard evidence of significant improvement over the simpler
> (current) design

 hmm, was it long ago? I'm seeing 480MB process for squid that uses
 300MB of memory (with 3M cached objects). This is 180MB overhead, and
 it is not a leak. Reducing this in half would be notable improvement.
 Although I also haven't yet seen hard evidence it would happen ;)

> the source pool still must be remembered for all objects

 search for right pool based on ptr would have much less overhead
 with chunks than it would be with current Pools. This could even
 be considered.

> - the current design can be used to pre-populate pools
> with sequentially pre-allocated objects, giving improvement
> that is probably close (in most cases) to that of a chunked
> design

 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.

 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.

> > this alignment is one of the major sources of memory waste. This is
> > a must for general purpose allocator I guess, but inside squid? Do we
> > have any places where 8/16 byte alignment is really required?
>
> Sure. If I want to allocate a "double" variable, it needs to be aligned.
> Structures that contain doubles must be aligned appropriately. Many
> platforms also require alignment for integers, AFAIK.

 hmm, how does compiler handle struct:
 struct {
    char b;
    double x;
   struct {
     int i;
     short s;
     char c;
     double y;
   }
 }
 does it really reorder them?
 malloc is known to return 8-aligned pointers. If there is an array of
 struct above, does compiler add alignment overhead between items?
 Then it should account for that in sizeof() also, right? But then
 chunked pools get created with right objsizes also.

 btw, does "double" need to be aligned only on 64-bit cpus?

> > I would like to align chunks on page boundaries, but I'd rather not
> > hardwire 8/16 alignment into all object allocations.
>
> I am not 100% sure, but I suspect that, in most cases, you will be safe
> if the chunks are allocated with calloc or even malloc _and_ used to
> store objects of equal size only. However,
> - I am not sure using malloc is safe on all platforms

 what else besides malloc? squid depends on malloc like nothing else
 already now. malloc is top-5 lib calls squid is making per second.
 If malloc is not safe, then how can squid survive at all?

> - if somebody tries to optimize mempools further (mmap or
> whatever), they may introduce alignment problems.

 Should add comments into memPools sources to warn against problems.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Wed Oct 18 2000 - 16:02:29 MDT