On 25 Sep 2000, at 18:57, Adrian Chadd <adrian@creative.net.au> wrote:
> > 1. Why do we need to always clear alloced memory?
> > memPool seems to only use calloc to actually get memory. When it gets
> > memory from pools, it doesn't clear it, instead it clears mem always
> > during free. Seems weird, although no difference.
>
> Squid assumes that a newly-allocated "thing" is zeroed. Its bitten me
> a few time. :)
>
> > memset adds some overhead, even if very small, it adds up (especially
> > on systems with limited CPU-ram bandwidth, like Intel). Do we actually
> > need to clear the membuffers? Maybe there would be reason to split
> > memPoolAlloc into separate versions: memPoolMalloc and memPoolCalloc?
>
> Most of the time you'd be zeroing it anyway unless you were reading in some
> socket buffer data.
well, for small structs this calloc isn't a problem. it might become one
with larger buffers. That is why I'm wondering if it makes sense to have
2 api calls into memPool stuff. Coders should use one that fits the needs,
and might use nonclearing calls when clearing is not needed, reducing CPU
load. Or should we think about adding memPoolCreate option for that?
> > 2. memPool does not try to align allocations at any size. calloc() does
> > it at small sizes (8). Maybe we should add a check that when allocations
> > of VM page size granularity occurs, we should use valloc() or memalign()
> > As Henrik has noted, this could speedup OS->userspace disk buffering by
> > reducing mem-mem copying. Also, if we tune dlmalloc.c to use mmaps for
> > allocations > 4-16KB, we could eventually somewhat reduce memory
> > fragmentation also.
>
> FreeBSD's malloc does page-align requests over a certain size. Feel free to
> try optimising the memPool stuff. :-)
I'll try.
------------------------------------
Andres Kroonmaa <andre@online.ee>
Delfi Online
Tel: 6501 731, Fax: 6501 708
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Mon Sep 25 2000 - 05:16:18 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:38 MST