git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Shawn Pearce <spearce@spearce.org>
Date
Sep 7, 2006, 05:58 UTC
Message-ID
<20060907055803.GE31580@spearce.org>
In-Reply-To
<7vodtt8l6v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
Show 5 quoted lines
> 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.

Show 11 quoted lines
> > 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.
Previous: Junio C HamanoNext: Jakub Narebski
Message 17 of 19 in “Some autoconf patches”
  1. 0/5 Some autoconf patchesJakub Narebski, Sep 4, 2006
  2. 1/5 autoconf: Add some commented out variables to config.mak.inJakub Narebski, Sep 4, 2006
  3. 2/5 autoconf: Add -liconv to LIBS when NEEDS_LIBICONVJakub Narebski, Sep 4, 2006
  4. Jonas FonsecaSep 5, 2006
  5. autoconf: Fix copy'n'paste errorJakub Narebski, Sep 5, 2006
  6. Junio C HamanoSep 5, 2006
  7. 3/5 autoconf: Preliminary check for working mmapJakub Narebski, Sep 4, 2006
  8. Junio C HamanoSep 4, 2006
  9. Jakub NarebskiSep 4, 2006
  10. Shawn PearceSep 5, 2006
  11. Junio C HamanoSep 5, 2006
  12. Shawn PearceSep 5, 2006
  13. Junio C HamanoSep 5, 2006
  14. Shawn PearceSep 6, 2006
  15. Junio C HamanoSep 6, 2006
  16. Junio C HamanoSep 6, 2006
  17. Shawn PearceSep 7, 2006
  18. 4/5 autoconf: Check for subprocess.pyJakub Narebski, Sep 4, 2006
  19. 5/5 autoconf: Quote AC_CACHE_CHECK argumentsJakub Narebski, Sep 4, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.