Linus Torvalds <torvalds@xxxxxxxx> writes: > On Fri, 5 Jan 2007, Linus Torvalds wrote: >> >> But it really shouldn't be a problem. > > Basically, this boils down to the same old issue: if you have a fixed > access pattern (like SHA1_Update() over the whole buffer), you're actually > likely to perform better with a loop of read() calls than with mmap. > > So if we ONLY did the SHA1 thing, we shouldn't do mmap, we should just > chunk things up into 16kB buffers or something, and read them. While I have your attention, there is a patch for the sliding mmap() thing that raises the mmap window to 1GB (which means a pack smaller than that is mmap'ed in its entirety, whle 2.3GB pack will be mapped perhaps as three separate chunks) and the total mmap window to 8GB (and any overflows we LRU out) on places where sizeof(void*) == 8 (i.e. git compiled for 64-bit). Currently these limits are 32MB and 256MB respectively on platforms with real mmap(). Do you have any comments on it? - 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