"Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html