From: Kjetil Barvik <barvik@broadpark.no>
To: Nicolas Pitre <nico@cam.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] avoid possible overflow in delta size filtering computation
Date: Thu, 26 Mar 2009 08:18:10 +0100 [thread overview]
Message-ID: <86y6usah1p.fsf@broadpark.no> (raw)
In-Reply-To: <alpine.LFD.2.00.0903251514360.26337@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 25 Mar 2009, Kjetil Barvik wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > On Wed, 25 Mar 2009, Kjetil Barvik wrote:
>> >
>> >> So, it seems that this patch almost fixed the issue. But notice that
>> >> the pack file was 10 bytes larger for the --depth=95000 case.
>> >>
>> >> I made a small perl script to compare the output from 'git verify-pack
>> >> -v' of the 2 idx/pack files, and found the following difference(1)
>> >> (first line from --depth=20000 case, second from --depth=95000):
>> >>
>> >> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 9 19 18921247 731 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d
>> >> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 20 29 18921247 730 12e560f7fb28558b15e3a2008fba860f9a4b2222
>> >
>> > OK. Apparently, a different base object for that one delta was chosen
>> > between those two runs.
>> >
>> > Is your machine SMP?
>>
>> kjetil ~$ uname -a
>> Linux localhost 2.6.28.4 #26 SMP PREEMPT Tue Feb 10 17:07:14 CET 2009
>> i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
>
> Here you go. If you want a perfectly deterministic repacking, you'll
> have to force the pack.threads config option to 1.
OK, have rerun the test again with pack.config set to 1, and got the
exact same result(1) as above this time also! :-)
And I think I can explain the reason for the same result: When the
--window and/or --depth value(s) is larger than (half?) the value of
possible number of objects (98438 in this time), I think that the
thread logic finds out that it can only run one thread (there is not
room/objects enough for 2 or more threads).
This also explains what I see when I run the repack command (without
the pack.config option), only 1 git process is running on 1 of the
CPU's from the start, and the other is idle.
~~
Give me a hint if you want some debug info from the 2 pack/idx files.
-- kjetil
1) The output from the 2 'git repack' commands did not show the
"running delta with 2 threads" (or something similar) this time.
I guess this is the sign that "pack.threads = 1" is working.
next prev parent reply other threads:[~2009-03-26 7:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 19:56 [PATCH] avoid possible overflow in delta size filtering computation Nicolas Pitre
2009-03-24 20:20 ` Brandon Casey
2009-03-24 20:52 ` Nicolas Pitre
2009-03-25 0:39 ` Nicolas Pitre
2009-03-25 12:15 ` Kjetil Barvik
2009-03-25 16:18 ` Nicolas Pitre
2009-03-25 16:34 ` Kjetil Barvik
2009-03-25 19:17 ` Nicolas Pitre
2009-03-26 7:18 ` Kjetil Barvik [this message]
2009-03-27 2:23 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y6usah1p.fsf@broadpark.no \
--to=barvik@broadpark.no \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.