On 29 Oct 2000, at 18:46, Henrik Nordstrom <hno@hem.passagen.se> wrote:
> Andres Kroonmaa wrote:
>
> > well, if its temporary, then its released.
>
> Except for the nasty effect that the temporary memory usage sometimes is
> in the reange of several hundred of MB...
could you describe a situation in more detail? you said:
> Well, there are still race conditions where the memobject can
> temporarily grow huge, so don't bet on it.
what race conditions should I keep in mind?
> > We can return memory in chunks
> > to the system. Probability that every chunk gets locked by few longliving
> > items is there, but should be pretty small because of first-fit approach.
> > Also, when chunks are large enough to justify mmap, such bursts would not
> > bang holes into heap.
>
> True, and malloc will automatically do this for us without forcing us to
> do chunked allocation if we increase the membuf block size somewhat..
I've put together a version of mempools with chunked allocations.
With 2.5M objects, and chunk size of 8K, I got very many chunks to handle.
I thought I'd increase chunk size for some specific pools, like StoreEntry,
MD5, heap_node, to 256K so that dlmalloc would place those onto mmaped area.
It does this, but quite selectively. For some reason it seems that it tries
to avoid using mmap, even for large allocations.
Now I wonder if it might be actually a bad idea to have too many mmapped
allocations for some reason. Any comments on that one?
------------------------------------
Andres Kroonmaa <andre@online.ee>
Delfi Online
Tel: 6501 731, Fax: 6501 708
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Mon Oct 30 2000 - 14:40:05 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:53 MST