On Jan 17, 2009, at 9:03 AM, Jeff Johnson wrote:
> There's also nothing wrong with the rpm.org power-of-2 block
> allocator except
> that I believe there's a deeper issue causing the fragmentation
> that will be buried if a block allocator is lashed on top.
I should point out that this fragmentation problem has only
been seen with rpm.org.
There's a uniqifier being added to rpmdb join keys (from OpenSUSE)
several years now. I'd be interested in hearing whether smart on
SuSE or with @rpm5.org has ever seen a "can't alloc" problem.
There's some other bog-standard techniques to reduce fragmentation
and malloc et al overhead that I can start adding @rpm5.org.
One technique is to run a chain of free'd items to avoid calling
malloc repeatedly, a previously allocated item is reused.
The other technique is to change to a slab allocator API instead.
Tools for looking at fragmentation, rather than leak detction, are
few and far between however. Anyone know of any good tools for
looking at fragmentation? Yes I know all the leak detector tools
quite well, I'm looking for something that will display statistics
on fragmentation, like largest available block in heap, and
identifiers attached to alloc's that are causing the fragmentation.
73 de Jeff
Received on Sat Jan 17 15:28:57 2009