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