From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jon Smirl <jonsmirl@gmail.com>, Nicolas Pitre <nico@cam.org>,
gcc@gcc.gnu.org, Git Mailing List <git@vger.kernel.org>
Subject: Re: Something is broken in repack
Date: Tue, 11 Dec 2007 11:40:22 -0800 [thread overview]
Message-ID: <7v7ijldnq1.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LFD.0.9999.0712111055590.25032@woody.linux-foundation.org> (Linus Torvalds's message of "Tue, 11 Dec 2007 11:17:08 -0800 (PST)")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 11 Dec 2007, Jon Smirl wrote:
>> >
>> > So if you want to use more threads, that _forces_ you to have a bigger
>> > memory footprint, simply because you have more "live" objects that you
>> > work on. Normally, that isn't much of a problem, since most source files
>> > are small, but if you have a few deep delta chains on big files, both the
>> > delta chain itself is going to use memory (you may have limited the size
>> > of the cache, but it's still needed for the actual delta generation, so
>> > it's not like the memory usage went away).
>>
>> This makes sense. Those runs that blew up to 4.5GB were a combination
>> of this effect and fragmentation in the gcc allocator. Google
>> allocator appears to be much better at controlling fragmentation.
>
> Yes. I think we do have some case where we simply keep a lot of objects
> around, and if we are talking reasonably large deltas, we'll have the
> whole delta-chain in memory just to unpack one single object.
Eh, excuse me. unpack_delta_entry()
- first unpacks the base object (this goes recursive);
- uncompresses the delta;
- applies the delta to the base to obtain the target object;
- frees delta;
- frees (but allows it to be cached) the base object;
- returns the result
So no matter how deep a chain is, you keep only one delta at a time in
core, not whole delta-chain in core.
> So what you actually want to do is to just re-use already packed delta
> chains directly, which is what we normally do. But you are explicitly
> looking at the "--no-reuse-delta" (aka "git repack -f") case, which is why
> it then blows up.
While that does not explain, as Nico pointed out, the huge difference
between the two repack runs that have different starting pack, I would
say it is a fair thing to say. If you have a suboptimal pack (i.e. not
enough reusable deltas, as in the 2.1GB pack case), do run "repack -f",
but if you have a good pack (i.e. 300MB pack), don't.
next prev parent reply other threads:[~2007-12-11 19:41 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-07 23:05 Something is broken in repack Jon Smirl
2007-12-08 0:37 ` Linus Torvalds
2007-12-08 1:27 ` [PATCH] pack-objects: fix delta cache size accounting Nicolas Pitre
2007-12-08 1:46 ` Something is broken in repack Nicolas Pitre
2007-12-08 2:04 ` Jon Smirl
2007-12-08 2:28 ` Nicolas Pitre
2007-12-08 3:29 ` Jon Smirl
2007-12-08 3:37 ` David Brown
2007-12-08 4:22 ` Jon Smirl
2007-12-08 4:30 ` Nicolas Pitre
2007-12-08 5:01 ` Jon Smirl
2007-12-08 5:12 ` Nicolas Pitre
2007-12-08 3:48 ` Harvey Harrison
2007-12-08 2:22 ` Jon Smirl
2007-12-08 3:44 ` Harvey Harrison
2007-12-08 22:18 ` Junio C Hamano
2007-12-09 8:05 ` Junio C Hamano
2007-12-09 15:19 ` Jon Smirl
2007-12-09 18:25 ` Jon Smirl
2007-12-10 1:07 ` Nicolas Pitre
2007-12-10 2:49 ` Nicolas Pitre
2007-12-08 2:56 ` David Brown
2007-12-10 19:56 ` Nicolas Pitre
2007-12-10 20:05 ` Jon Smirl
2007-12-10 20:16 ` Morten Welinder
2007-12-11 2:25 ` Jon Smirl
2007-12-11 2:55 ` Junio C Hamano
2007-12-11 3:27 ` Nicolas Pitre
2007-12-11 11:08 ` David Kastrup
2007-12-11 12:08 ` Pierre Habouzit
2007-12-11 12:18 ` David Kastrup
2007-12-11 3:49 ` Nicolas Pitre
2007-12-11 5:25 ` Jon Smirl
2007-12-11 5:29 ` Jon Smirl
2007-12-11 7:01 ` Jon Smirl
2007-12-11 7:34 ` Andreas Ericsson
2007-12-11 13:49 ` Nicolas Pitre
2007-12-11 15:00 ` Nicolas Pitre
2007-12-11 15:36 ` Jon Smirl
2007-12-11 16:20 ` Nicolas Pitre
2007-12-11 16:21 ` Jon Smirl
2007-12-12 5:12 ` Nicolas Pitre
2007-12-12 8:05 ` David Kastrup
2007-12-14 16:18 ` Wolfram Gloger
2007-12-12 15:48 ` Nicolas Pitre
2007-12-12 16:17 ` Paolo Bonzini
2007-12-12 16:37 ` Linus Torvalds
2007-12-12 16:42 ` David Miller
2007-12-12 16:54 ` Linus Torvalds
2007-12-12 17:12 ` Jon Smirl
2007-12-14 16:12 ` Wolfram Gloger
2007-12-14 16:45 ` David Kastrup
2007-12-14 16:59 ` Wolfram Gloger
2007-12-13 13:32 ` Nguyen Thai Ngoc Duy
2007-12-13 15:32 ` Paolo Bonzini
2007-12-13 16:29 ` Paolo Bonzini
2007-12-13 16:39 ` Johannes Sixt
2007-12-14 1:04 ` Jakub Narebski
2007-12-14 6:14 ` Paolo Bonzini
2007-12-14 6:24 ` Nguyen Thai Ngoc Duy
2007-12-14 8:20 ` Paolo Bonzini
2007-12-14 9:01 ` Harvey Harrison
2007-12-14 10:40 ` Jakub Narebski
2007-12-14 10:52 ` Nguyen Thai Ngoc Duy
2007-12-14 13:25 ` Nicolas Pitre
2007-12-12 16:13 ` Nicolas Pitre
2007-12-13 7:32 ` Andreas Ericsson
2007-12-14 16:03 ` Wolfram Gloger
2007-12-11 16:33 ` Linus Torvalds
2007-12-11 17:21 ` Nicolas Pitre
2007-12-11 17:24 ` David Miller
2007-12-11 17:44 ` Nicolas Pitre
2007-12-11 20:26 ` Andreas Ericsson
2007-12-11 18:43 ` Jon Smirl
2007-12-11 18:57 ` Nicolas Pitre
2007-12-11 19:17 ` Linus Torvalds
2007-12-11 19:40 ` Junio C Hamano [this message]
2007-12-11 20:34 ` Andreas Ericsson
2007-12-11 17:28 ` Daniel Berlin
2007-12-11 13:31 ` Nicolas Pitre
2007-12-11 6:01 ` Sean
2007-12-11 6:20 ` Jon Smirl
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=7v7ijldnq1.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=gcc@gcc.gnu.org \
--cc=git@vger.kernel.org \
--cc=jonsmirl@gmail.com \
--cc=nico@cam.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).