On Tue, Dec 11, 2007 at 11:08:47AM +0000, David Kastrup wrote: > Nicolas Pitre <nico@xxxxxxx> writes: > > > On Mon, 10 Dec 2007, Junio C Hamano wrote: > > > >> "Jon Smirl" <jonsmirl@xxxxxxxxx> writes: > >> > >> > 95% 530 2.8G - 1,420 total to here, previous was 1,983 > >> > 100% 1390 2.85G > >> > During the writing phase RAM fell to 1.6G > >> > What is being freed in the writing phase?? > >> > >> entry->delta_data is the only thing I can think of that are freed > >> in the function that have been allocated much earlier before entering > >> the function. > > > > Yet all ->delta-data instances are limited to 256MB according to Jon's > > config. > > Maybe address space fragmentation is involved here? malloc/free for > large areas works using mmap in glibc. There must be enough > _contiguous_ space for a new allocation to succeed. Well, that's interesting, but there is a way to know for sure instead of taking bets. Just use valgrind --tool=massif and look at the pretty picture, it'll tell what was going on very accurately. Note that I find your explanation unlikely: glibc uses mmap for sizes over 128k by default (IIRC), and as soon as you use mmaps, that's the kernel that deals with the address space, and it's not necessarily contiguous, that's only true for the heap. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpxS41hhdnVc.pgp
Description: PGP signature
