Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.
Date: Thu, 04 Jan 2007 22:01:20 -0800	[thread overview]
Message-ID: <7v4pr6j9lb.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20070105032808.GA14247@spearce.org> (Shawn O. Pearce's message of "Thu, 4 Jan 2007 22:28:08 -0500")

"Shawn O. Pearce" <spearce@spearce.org> writes:

> If we have a 64 bit address space we can easily afford to commit
> a larger amount of virtual address space to pack file access.
> So on these platforms we should increase the default settings of
> core.packedGit{Limit,WindowSize} to something that will better
> handle very large projects.

Hmmmm.  What's the reasoning behind this?

We have more than enough virtual memory anyway, we do not bother
with our own mmap limit -- we will let the operating system
worry about it.

If that is the reasoning, I have a feeling that we might want to
be even more agressive.  If you have a 1.5GB pack, wouldn't you
rather map the whole thing in a single window, instead of
splitting that into two?

Currently we are limited (by pack offset) to 4GB per pack, so
raising the window max to 4GB might make sense.

On the total size of vm space, I am wondering what would happen
if we make this unbounded.  You certainly notice mmap() failure
and fall back to recycle other windows even when your total
usage is under the limit, don't you?  Your later patches in the
series even unmap the mapped but unused window lazily to make
room for xmalloc() and friends, so I suspect it might even make
it simpler not to have this limit especially on larger systems.

      reply	other threads:[~2007-01-05  6:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-05  3:28 [PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems Shawn O. Pearce
2007-01-05  6:01 ` Junio C Hamano [this message]

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=7v4pr6j9lb.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.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