Re: [PATCH] macOS: queue for munmap operations

[Jeff King <peff@peff.net>]

On Wed, Oct 22, 2025 at 10:21:32AM +0900, Koji Nakamaru wrote:

> > Ditto here. I'd be curious how well packed the repo is, and how it does
> > after a repack. If it has a very large packfile, you might also try:
> >
> >   git config core.packedGitWindowSize 4G
> >
> > or similar (though for just an ls-tree, we should only be looking at
> > tree objects, which in general I'd expect to be in a confined area of
> > the packfile; so the 1GB window is probably plenty).
> 
> Following your suggestion, I investigated the number of mmap calls in
> other environments and found much smaller counts. I tracked how
> xmmap_gently() was called in packfile.c and found
> settings->packed_git_window_size was different between environments. My
> ~/.gitconfig defined "packedGitLimit = 128m" and this caused many calls.

Ah, very interesting. Yes, I think that helps explain why there were so
many mmap calls. I don't think there's a good reason to lower that
number in general, assuming the OS is reasonably good at dropping mapped
pages from RAM when there's memory pressure.

> In my extreme cases, this batching makes them faster. Queue flushing has
> occurred several times for the private repository case and not occurred
> for the Linux kernel case. Though I haven't investigated in detail,
> memory pressure doesn't seem to be critical (and it could also be
> possible to adopt smarter thresholds).

OK, that's quite interesting that batching makes such a difference. I
guess somebody with more knowledge of macOS kernel internals could
probably explain it. Though it sounds like your problem was sufficiently
solved by dropping the extra config, it's a good fact for us to know
about in general.

-Peff