On 03/25/2011 10:24 PM, Martin Sustrik wrote:
> Say I am allocating a buffer of 16kB. The allocator may or may not
> prepend it by chunk header. In the former case the actual size of the
> allocated memory will be slightly higher, say 16.1kB. Which means that
> instead of using 3 full pages, it will require one additional, almost
> empty page. Which in turn means higher memory consumption and, possibly,
> fragmentation.
>
> Is there a rule of thumb to prevent such behaviour? Something like:
> always allocated N * page-size - 256 or somesuch?
There is no good rule of thumb I know of; allocators differ enough in
their implementation details that you're better off dynamically probing
the allocator's behavior. It's reasonably straightforward to find out
what the size class boundaries are for jemalloc via its mallctl() API.
In general though, you could do a series of allocations at startup to
dynamically discover the size classes, e.g.
for (size_t sz = 0; sz < SOME_LIMIT; ) {
void *p = malloc(sz + 1);
if (p == NULL)
abort(); // Or something...
sz = malloc_usable_size(p);
printf("Size class: %zu\n", sz);
free(p);
}
This will work for glibc, tcmalloc, jemalloc, and many others on Linux.
The approach will also work on OS X, though you need to use
malloc_size() (or better, avoid the malloc()/free() calls and use
malloc_good_size() instead).
Jason
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
