Re: Something is broken in repack
- From
Andreas Ericsson <ae@op5.se>
- Date
- Dec 13, 2007, 07:32 UTC
- Message-ID
- <4760E005.6040102@op5.se>
- In-Reply-To
- <alpine.LFD.0.99999.0712121106400.555@xanadu.home>
Nicolas Pitre wrote:
Show 36 quoted lines
> 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 <malloc.h>
>> #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