Re: git-svnimport failed and now git-repack hates me

Linus Torvalds [off-list ref] writes:

On Fri, 5 Jan 2007, Linus Torvalds wrote:

quoted

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?

On Fri, 5 Jan 2007, Junio C Hamano wrote:

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?

I think it's fine. Most "normal" mmap users hopefully will only use a 
small portion of the mapped space, adn if they use it all, it means that 
they needed it all, so..

		Linus