From: Junio C Hamano <gitster@pobox•com>
To: Duy Nguyen <pclouds@gmail•com>
Cc: David Kastrup <dak@gnu•org>, Git Mailing List <git@vger•kernel.org>
Subject: Re: [PATCH v2] Bump core.deltaBaseCacheLimit to 128MiB
Date: Thu, 20 Mar 2014 10:02:39 -0700 [thread overview]
Message-ID: <xmqqsiqcztu8.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8C3=bz1HmVgQuJRdixMhhb-JKouM7b1L7M047L_4PBViA@mail.gmail.com> (Duy Nguyen's message of "Thu, 20 Mar 2014 08:38:18 +0700")
Duy Nguyen <pclouds@gmail•com> writes:
> On Thu, Mar 20, 2014 at 5:11 AM, Junio C Hamano <gitster@pobox•com> wrote:
> ...
>> I know that the 512MiB default for the bitFileThreashold (aka
>> "forget about delta compression") came out of thin air. It was just
>> "1GB is always too huge for anybody, so let's cut it in half and
>> declare that value the initial version of a sane threashold",
>> nothing more.
>>
>> So it might be that the problem is 512MiB is still too big, relative
>> to the 16MiB of delta base cache, and the former may be what needs
>> to be tweaked. If a blob close to but below 512MiB is a problem for
>> 16MiB delta base cache, it would still be too big to cause the same
>> problem for 128MiB delta base cache---it would evict all the other
>> objects and then end up not being able to fit in the limit itself,
>> busting the limit immediately, no?
>>
>> I would understand if the change were to update the definition of
>> deltaBaseCacheLimit and link it to the value of bigFileThreashold,
>> for example. With the presented discussion, I am still not sure if
>> we can say that bumping deltaBaseCacheLimit is the right solution to
>> the "description with the current setting is clearly wrong" (which
>> is a real issue).
>
> I vote make big_file_threshold smaller. 512MB is already unfriendly
> for many smaller machines. I'm thinking somewhere around 32MB-64MB
> (and maybe increase delta cache base limit to match).
These numbers match my gut feeling (e.g. 4k*4k*32-bit uncompressed
would be 64MB); delta cash base that is sized to the same as (or
perhaps twice as big as) that limit may be a good default.
> The only
> downside I see is large blobs will be packed undeltified, which could
> increase pack size if you have lots of them.
I think that is something that can be tweaked, unless the user tells
us otherwise via command line override, when running the improved
"gc --aggressive" ;-)
next prev parent reply other threads:[~2014-03-20 17:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 12:38 [PATCH v2] Bump core.deltaBaseCacheLimit to 128MiB David Kastrup
2014-03-19 21:09 ` Junio C Hamano
2014-03-19 21:25 ` David Kastrup
2014-03-19 22:11 ` Junio C Hamano
2014-03-20 1:38 ` Duy Nguyen
2014-03-20 17:02 ` Junio C Hamano [this message]
2014-03-20 17:08 ` David Kastrup
2014-03-20 22:35 ` Junio C Hamano
2014-03-21 6:04 ` David Kastrup
2014-03-21 7:59 ` Duy Nguyen
2014-03-21 8:02 ` David Kastrup
2014-03-20 23:48 ` Jeff King
2014-03-21 6:12 ` David Kastrup
2014-03-21 8:11 ` David Kastrup
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=xmqqsiqcztu8.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=dak@gnu$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=pclouds@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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