CC: | Tomas Hozza <thozza@redhat.com> |
Subject: | freelists in memory context consume memory indefinitely |
Date: | Tue, 07 Jan 2014 21:09:34 +0100 |
To: | bind9-bugs@isc.org |
From: | Petr Spacek <pspacek@redhat.com> |
Hello,
I would like to ask you about details of memory context behavior in BIND
9.9.3-P2, some details seems weird to me. May be that it is a bug or I just
misunderstood something ...
Thank you very much for your time!
I think that small memory blocks which are referenced by "struct
isc__mem->freelists" are never freed (I mean returned to the operating system)
until the memory context is destroyed, right?
I'm attaching small demonstration program which does this:
0) create() empty memory context
1) get() 1 million of 1 KiB blocks
2) put() all the blocks back to the mctx
3) destroy() mctx
The program pauses after each step which allows to investigate memory
consumption as seen by the operating system.
I compile it with:
gcc -std=c99 -ldns -lisc -I/usr/include/bind9 -g -O0 -o mctx mctx.c
I understand that freelists mechanism saves overhead of the operating system
allocator for small blocks, but I'm missing a way how to 'flush' freelists.
Use case:
I'm developing a database driver for BIND 9 and I'm in situation when the
driver does a lot of small allocations during zone loading. My problem is that
after initial processing the driver "puts" most of the small blocks back to
the mctx but this memory is not returned back to the operating system.
I'm not sure if this problem deserves own function for explicit 'freelists
flush', but generally I could use that in my code.
May be that solution like "automatically flush freelists
if ((total - inuse) > inuse)" would be good enough and even the plain BIND
could benefit from that.
May be that factor 2 is too big, may be that and 1/2 would be more appropriate ...
if ((total - inuse) > (inuse >> 1))
Could you recommend something else to me if the approaches mentioned above are
not feasible?
Thank you very much for your patience with me :-)
--
Petr Spacek
Red Hat
Message body is not shown because sender requested not to inline it.