Date: Wed, 22 Mar 2006 10:14:16 -0800 From: Jason Evans <jasone@FreeBSD.org> To: Chuck Swiger <cswiger@mac.com> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, current@freebsd.org Subject: Re: core dumps are HUGE... Message-ID: <442193F8.7070104@FreeBSD.org> In-Reply-To: <44215B1B.1080104@mac.com> References: <20060321184019.GX35129@funkthat.com> <47CC5AC0-1B44-4485-92A9-70751681A527@freebsd.org> <20060321222046.GY35129@funkthat.com> <1EB2EEE3-855C-4B76-81A6-1880526797CE@freebsd.org> <44215B1B.1080104@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Swiger wrote: > Can jemalloc only create per-CPU arenas only for processes which are themselves > multithreaded, when it's running on a multi-CPU system? Would that help reduce > the amount of allocated but unreferenced memory that is involved for the common > case of /bin/sh and friends? jemalloc already lazily creates arenas (and the associated chunks), so support for multi-threaded programs costs single-threaded programs practially nothing. Here's why a typical small program has a ~6 MB VSIZE on i386. Chunks have to be aligned at addresses that are multiples of the chunk size. Since the heap doesn't start at a chunk-aligned address, the first chunk that can be allocated from the heap is well past the beginning of the heap. Additionally, we need at least *two* chunks -- one for internal malloc data structures and one for application allocations. At the cost of a bit of extra complexity, it is possible to start off with a runt chunk for the internal malloc data structures, since the chunk alignment requirements happen to be unimportant for internally used chunks. This would reduce VSIZE somewhat. It isn't clear to me that this optimization is worthwhile overall (though I do have a patch that implements it). This problem doesn't even exist for the 64-bit architectures, since there we use mmap() for all chunks. Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442193F8.7070104>