Junio C Hamano <junkio@cox.net> wrote:
quoted text
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > ...  Although it would add
> > a new pair of configuration options to .git/config.  Is that change
> > too radical?  :-)
> 
> I wonder what you would need the configuration options for.
> 
> If mmap() pack works well, it works well, and if it is broken
> nobody has reason to enable it.  The code should be able to
> adjust the mmap window to appropriate size itself and its
> automatic adjustment does not even have to be the absolute
> optimum (since the user would not know what the optimum would be
> anyway), so maybe your configuration options would not be
> "enable" nor "window-size" -- and I am puzzled as to what they

All very true.

However what do we do about the case where we mmap over 1 GiB worth
of pack data (because the mmap succeeds and we have at least that
much in .pack and .idx files) and then the application starts to
demand a lot of memory via malloc?  At some point malloc will return
NULL, xmalloc will die(), and that's the end of the program.

If the user was able to set the maximum threshold of how much data
we mmap then they could initially prevent us from mmap'ing over 1 GiB;
instead using a smaller upper limit like 512 MiB.

Of course as I write this I think the better solution to this
problem is to simply modify xmalloc (and friends) so that if the
underlying malloc returned NULL and we have a large amount of stuff
mmap'd from packs we try releasing some of the unused pack windows
and retry the malloc before die()'ing.


The other configuration option is the size of the mmap window.
This should by default be at least 32 MiB, probably closer to
128 MiB.  But its nice to be able to force it as low as a single
system page to setup test cases in the t/ directory for the mmap
window code.

Earlier this summer we discussed this exact issue and said this
value probably needs to be configurable if only to facilitate the
unit tests.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html