From: Jeff King Date: Wed, 22 Oct 2025 09:05:39 GMT Subject: Re: [PATCH] macOS: queue for munmap operations Message-ID: <20251022090539.GA853931@coredump.intra.peff.net> In-Reply-To: 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