Re: [PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.

From: Junio C Hamano <junkio@cox.net>
Date: Jan 5, 2007, 06:01 UTC
Message-ID: <7v4pr6j9lb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070105032808.GA14247@spearce.org>

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

Show 5 quoted lines

> 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.