|
From: Julian S. <js...@ac...> - 2007-07-13 08:35:00
|
> after about 10 hours of runtime arena_malloc begins to use more and more of > runtime. After 15 hours arena_malloc uses around 25%. This is after applying your Superblock fix and Hashtable fix, yes? > Is there a document that describes the workings of the arena > implementation? It would help to reason about the causes of such a > behaviour. Each arena has a set of N_MALLOC_LISTS circular double-linked lists of free blocks, classified by size (see pszB_to_listNo). I think each list arbitrarily travels across all the Superblocks in the Arena. The arena's freelist[] array contains pointers to some arbitrary entry point in each list. When a block is freed it is put back on the relevant list, and swizzle is then called as an anti-fragmentation kludge. (see comments on that function) Some list contains blocks from a variety of sizes. eg list 15 contains blocks with sizes 33*VG_MIN_MALLOC_SZB to 64*VG_MIN_MALLOC_SZB. So if arena_malloc is doing a lot of searching, it could be because there are a large number of frees which put blocks back on the list, but these blocks are too small to satisfy the next malloc from that list and so there is a lot of searching to find the next big-enough block on the list. Maybe worth investigating the per-list behaviour of your application. Maybe need more different lists per Arena? J |