Junio C Hamano <junkio@xxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html