Re: [PATCH 3/5] autoconf: Preliminary check for working mmap

[Shawn Pearce <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> Well, if you are talking about git.git t/ directory, I bet that
> "the full test suite" easily fits in a single window so much of
> the new code is not exercised, unless you have a runtime option
> to make use of very tiny window (32kB would be nice) for testing
> ;-).

Heh.  t/ passed which meant basic rev listing and verify-pack
appeared OK.  I hardcoded the window size to be 2*getpagesize() (8192
bytes on my Mac OS X system) and started beating up Git against its
own 8 MiB pack.  The window code opened a ton of windows at once as
the PACK_MAX_SZ was 128 MiB.  So I hardcoded that to be 16384 bytes.
And the code worked right against the 8 MiB Git pack by opening
only 4 windows at once and closing the least-recently-used one.

I can easily parameterize both values in .git/config; there's no
real reason for them to be hardcoded.  That should make it easier
to craft some new test cases that push the windowing code.

> > I am going to rebase the changes to the 64 bit index in `pu`
> > and clean up my history.  Its currently one massive commit with
> > lots of changes that should be broken down into slightly more
> > digestable chunks.
> 
> Breaking things up would be nice.  Do you have a good testcase
> out of Mozilla repository that _needs_ 64-bit index?  The code
> in "pu" uses 64-bit index only 32-bit offset cannot describe the
> pack, so I only tested with an artificial case with the kernel
> archive with .idx converted with convert-idx to 64-bit.
> 

Not really.  We know the Mozilla pack decompressed is around 20 GiB.
I could decompress it and repack it using no deltas; that should
exceed 4 GiB.  It will take quite some time to run the decompression
and delta inflates, especially with the highly-compressed 450 MiB
pack Jon Smirl sent me.  I can do that kind of testing maybe later
next week after I get my new amd64 system built.

-- 
Shawn.