Re: [PATCH] macOS: queue for munmap operations
- From
Jeff King <peff@peff.net>
- Date
- Oct 22, 2025, 09:05 UTC
- Message-ID
- <20251022090539.GA853931@coredump.intra.peff.net>
- In-Reply-To
- <CAOTNsDxoSFTBwaO0Eqr+r0NQOwdA2Fge3CN7JQtnAWEt2PnDew@mail.gmail.com>
On Wed, Oct 22, 2025 at 10:21:32AM +0900, Koji Nakamaru wrote:
Show 14 quoted lines
> > 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.
Show 5 quoted lines
> 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