From: Andreas Ericsson Date: Thu, 13 Dec 2007 07:32:21 GMT Subject: Re: Something is broken in repack Message-ID: <4760E005.6040102@op5.se> In-Reply-To: Nicolas Pitre wrote: > On Wed, 12 Dec 2007, Nicolas Pitre wrote: > >> I did modify the progress display to show accounted memory that was >> allocated vs memory that was freed but still not released to the system. >> At least that gives you an idea of memory allocation and fragmentation >> with glibc in real time: >> >> diff --git a/progress.c b/progress.c >> index d19f80c..46ac9ef 100644 >> --- a/progress.c >> +++ b/progress.c >> @@ -8,6 +8,7 @@ >> * published by the Free Software Foundation. >> */ >> >> +#include >> #include "git-compat-util.h" >> #include "progress.h" >> >> @@ -94,10 +95,12 @@ static int display(struct progress *progress, unsigned n, const char *done) >> if (progress->total) { >> unsigned percent = n * 100 / progress->total; >> if (percent != progress->last_percent || progress_update) { >> + struct mallinfo m = mallinfo(); >> progress->last_percent = percent; >> - fprintf(stderr, "%s: %3u%% (%u/%u)%s%s", >> - progress->title, percent, n, >> - progress->total, tp, eol); >> + fprintf(stderr, "%s: %3u%% (%u/%u) %u/%uMB%s%s", >> + progress->title, percent, n, progress->total, >> + m.uordblks >> 18, m.fordblks >> 18, >> + tp, eol); > > Note: I didn't know what unit of memory those blocks represents, so the > shift is most probably wrong. > Me neither, but it appears to me as if hblkhd holds the actual memory consumed by the process. It seems to store the information in bytes, which I find a bit dubious unless glibc has some internal multiplier. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231