On Wed, Jun 30, 2021 at 12:01:32AM +0000, Eric Wong wrote: > This series is now down to a single patch. > > I wanted to make things more transparent to users without > privileges to raise sys.vm.max_map_count and/or RLIMIT_DATA; > but it doesn't seem possible to account for libc/zlib/etc. doing > mmap() without our knowledge (usually via malloc). Oh, I should have read this one before reviewing the inner parts of v1. :) In general I agree that trying to manage our map count can never be foolproof. As you note, other parts of the system may contribute to that count. But even within Git, we don't have any mechanism for unmapping many non-packfiles. So if you have 30,000 packs, you may hit the limit purely via the .idx files (and ditto for the new .rev files, and probably commit-graph files, etc). That said, I'm not opposed to handling xmmap() failures more gracefully, as your series did. It's not foolproof, but it might help in some cases. > So I think giving users some information to feed their sysadmins > is the best we can do in this situation: This seems OK to me, too. Translators might complain a bit about the message-lego. I don't have a strong opinion. -Peff
