{"thread":{"id":"64359","subject":"[PATCH] macOS: queue for munmap operations","startedAt":"2025-10-20T22:35:05Z","lastAt":"2025-10-22T09:05:50Z","messageCount":6,"participants":["Koji Nakamaru via GitGitGadget","Torsten Bögershausen","Jeff King","Koji Nakamaru"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"529209","messageId":"pull.1993.git.1760999702581.gitgitgadget@gmail.com","threadId":"64359","inReplyTo":null,"subject":"[PATCH] macOS: queue for munmap operations","fromName":"Koji Nakamaru via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2025-10-20T22:35:02Z","receivedAt":"2025-10-20T22:35:05Z","isPatch":true,"sender":{"key":"koji.nakamaru@gree.net","avatar":"https://avatars.githubusercontent.com/u/2645978?v=4"},"body":"From: Koji Nakamaru <koji.nakamaru@gree.net>\n\nExecuting many mmap/munmap calls alternately can cause a huge load on\nmacOS. In order to reduce it, we should temporarily store munmap\noperations in a queue and process them all at once when the queue is\nfilled. When the program terminates, we can discard any remaining munmap\noperations as corresponding mmaped regions are automatically reclaimed.\n\nAdd a queue for munmap operations to perform them all at once.\n\nHere are some example timings. On the Linux kernel repository that\nrequires about 1700 mmap/munmap calls:\n\n  time git ls-tree -r -l --full-tree 211ddde > /dev/null\n\n  Before:\n        real    0m2.083s\n        user    0m0.201s\n        sys     0m1.873s\n\n  After:\n        real    0m0.243s\n        user    0m0.179s\n        sys     0m0.052s\n\nOn a private repository that requires about 943000 mmap/munmap calls:\n\n  time git ls-tree -r -l --full-tree xxxxxxx > /dev/null\n\n  Before:\n        real    27m15.138s\n        user    0m5.084s\n        sys     27m9.636s\n\n  After:\n        real    0m24.209s\n        user    0m3.055s\n        sys     0m21.123s\n\nSigned-off-by: Koji Nakamaru <koji.nakamaru@gree.net>\n---\n    macOS: queue for munmap operations\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1993%2FKojiNakamaru%2Ffeature%2Fosx-queued-munmap-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1993/KojiNakamaru/feature/osx-queued-munmap-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1993\n\n Makefile                            |  1 +\n compat/osxmmap.c                    | 49 +++++++++++++++++++++++++++++\n compat/posix.h                      |  7 +++++\n contrib/buildsystems/CMakeLists.txt |  4 +++\n meson.build                         |  2 ++\n 5 files changed, 63 insertions(+)\n create mode 100644 compat/osxmmap.c\n\ndiff --git a/Makefile b/Makefile\nindex f79c905bdc..058bc83753 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1654,6 +1654,7 @@ ifeq ($(uname_S),Darwin)\n \t\tCOMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO\n         endif\n \tPTHREAD_LIBS =\n+\tCOMPAT_OBJS += compat/osxmmap.o\n endif\n \n ifdef NO_LIBGEN_H\ndiff --git a/compat/osxmmap.c b/compat/osxmmap.c\nnew file mode 100644\nindex 0000000000..5f9cf633ca\n--- /dev/null\n+++ b/compat/osxmmap.c\n@@ -0,0 +1,49 @@\n+#include <pthread.h>\n+#include \"../git-compat-util.h\"\n+/* We need original mmap/munmap here. */\n+#undef mmap\n+#undef munmap\n+\n+/*\n+ * OSX doesn't have any specific setting like Linux's vm.max_map_count,\n+ * so COUNT_MAX can be any large number. We here set it to the default\n+ * value of Linux's vm.max_map_count.\n+ */\n+#define COUNT_MAX (65530)\n+\n+struct munmap_queue {\n+\tvoid *start;\n+\tsize_t length;\n+};\n+\n+void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)\n+{\n+\t/*\n+\t * We can simply discard munmap operations in the queue by\n+\t * restricting mmap arguments.\n+\t */\n+\tif (start != NULL || flags != MAP_PRIVATE || prot != PROT_READ)\n+\t\tdie(\"invalid usage of mmap\");\n+\treturn mmap(start, length, prot, flags, fd, offset);\n+}\n+\n+int git_munmap(void *start, size_t length)\n+{\n+\tstatic pthread_mutex_t mutex;\n+\tstatic struct munmap_queue *queue;\n+\tstatic int count;\n+\tint i;\n+\n+\tpthread_mutex_lock(&mutex);\n+\tif (!queue)\n+\t\tqueue = xmalloc(COUNT_MAX * sizeof(struct munmap_queue));\n+\tqueue[count].start = start;\n+\tqueue[count].length = length;\n+\tif (++count == COUNT_MAX) {\n+\t\tfor (i = 0; i < COUNT_MAX; i++)\n+\t\t\tmunmap(queue[i].start, queue[i].length);\n+\t\tcount = 0;\n+\t}\n+\tpthread_mutex_unlock(&mutex);\n+\treturn 0;\n+}\ndiff --git a/compat/posix.h b/compat/posix.h\nindex 067a00f33b..3fa1218289 100644\n--- a/compat/posix.h\n+++ b/compat/posix.h\n@@ -278,6 +278,13 @@ int git_munmap(void *start, size_t length);\n \n #include <sys/mman.h>\n \n+#if defined(__APPLE__)\n+#define mmap git_mmap\n+#define munmap git_munmap\n+void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);\n+int git_munmap(void *start, size_t length);\n+#endif\n+\n #endif /* NO_MMAP || USE_WIN32_MMAP */\n \n #ifndef MAP_FAILED\ndiff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\nindex edb0fc04ad..5c08f2fe5c 100644\n--- a/contrib/buildsystems/CMakeLists.txt\n+++ b/contrib/buildsystems/CMakeLists.txt\n@@ -271,6 +271,10 @@ if(CMAKE_SYSTEM_NAME STREQUAL \"Windows\")\n \t\tcompat/strdup.c)\n \tset(NO_UNIX_SOCKETS 1)\n \n+elseif(CMAKE_SYSTEM_NAME STREQUAL \"Darwin\")\n+\tlist(APPEND compat_SOURCES\n+\t\tcompat/osxmmap.c)\n+\n elseif(CMAKE_SYSTEM_NAME STREQUAL \"Linux\")\n \tadd_compile_definitions(PROCFS_EXECUTABLE_PATH=\"/proc/self/exe\" HAVE_DEV_TTY )\n \tlist(APPEND compat_SOURCES unix-socket.c unix-stream-server.c compat/linux/procinfo.c)\ndiff --git a/meson.build b/meson.build\nindex cee9424475..b9b6e731b1 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -1275,6 +1275,8 @@ elif host_machine.system() == 'windows'\n   else\n     libgit_sources += 'compat/mingw.c'\n   endif\n+elif host_machine.system() == 'darwin'\n+  libgit_sources += 'compat/osxmmap.c'\n endif\n \n if host_machine.system() == 'linux'\n\nbase-commit: 4253630c6f07a4bdcc9aa62a50e26a4d466219d1\n-- \ngitgitgadget\n"},{"id":"529218","messageId":"20251021062621.GA370@tb-raspi4","threadId":"64359","inReplyTo":"pull.1993.git.1760999702581.gitgitgadget@gmail.com","subject":"Re: [PATCH] macOS: queue for munmap operations","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-10-21T06:26:21Z","receivedAt":"2025-10-21T06:26:25Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"Some comments inline, all up to improvements\n\nOn Mon, Oct 20, 2025 at 10:35:02PM +0000, Koji Nakamaru via GitGitGadget wrote:\n> From: Koji Nakamaru <koji.nakamaru@gree.net>\n> \n> Executing many mmap/munmap calls alternately can cause a huge load on\n> macOS. In order to reduce it, we should temporarily store munmap\n> operations in a queue and process them all at once when the queue is\n> filled. When the program terminates, we can discard any remaining munmap\n> operations as corresponding mmaped regions are automatically reclaimed.\n> \n> Add a queue for munmap operations to perform them all at once.\n> \n\nSuggestions for rewording:\nIn order to reduce the peak load store all munmap operations in a queue.\nProcess them all at once (and more efficient) when the queue is filled.\nThe queue may be ignored when the git process terminates. The operating\nsystem will do all munmap() when the process exits.\n\n> Here are some example timings. On the Linux kernel repository that\n> requires about 1700 mmap/munmap calls:\n> \n>   time git ls-tree -r -l --full-tree 211ddde > /dev/null\n> \n>   Before:\n>         real    0m2.083s\n>         user    0m0.201s\n>         sys     0m1.873s\n> \n>   After:\n>         real    0m0.243s\n>         user    0m0.179s\n>         sys     0m0.052s\n> \n> On a private repository that requires about 943000 mmap/munmap calls:\n> \n>   time git ls-tree -r -l --full-tree xxxxxxx > /dev/null\n> \n>   Before:\n>         real    27m15.138s\n>         user    0m5.084s\n>         sys     27m9.636s\n> \n>   After:\n>         real    0m24.209s\n>         user    0m3.055s\n>         sys     0m21.123s\n> \n> Signed-off-by: Koji Nakamaru <koji.nakamaru@gree.net>\n> ---\n>     macOS: queue for munmap operations\n> \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1993%2FKojiNakamaru%2Ffeature%2Fosx-queued-munmap-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1993/KojiNakamaru/feature/osx-queued-munmap-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1993\n> \n>  Makefile                            |  1 +\n>  compat/osxmmap.c                    | 49 +++++++++++++++++++++++++++++\n>  compat/posix.h                      |  7 +++++\n>  contrib/buildsystems/CMakeLists.txt |  4 +++\n>  meson.build                         |  2 ++\n>  5 files changed, 63 insertions(+)\n>  create mode 100644 compat/osxmmap.c\n> \n> diff --git a/Makefile b/Makefile\n> index f79c905bdc..058bc83753 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -1654,6 +1654,7 @@ ifeq ($(uname_S),Darwin)\n>  \t\tCOMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO\n>          endif\n>  \tPTHREAD_LIBS =\n> +\tCOMPAT_OBJS += compat/osxmmap.o\n>  endif\n>  \n>  ifdef NO_LIBGEN_H\n> diff --git a/compat/osxmmap.c b/compat/osxmmap.c\n> new file mode 100644\n> index 0000000000..5f9cf633ca\n> --- /dev/null\n> +++ b/compat/osxmmap.c\n> @@ -0,0 +1,49 @@\n> +#include <pthread.h>\n> +#include \"../git-compat-util.h\"\n> +/* We need original mmap/munmap here. */\n> +#undef mmap\n> +#undef munmap\n> +\n> +/*\n> + * OSX doesn't have any specific setting like Linux's vm.max_map_count,\n> + * so COUNT_MAX can be any large number. We here set it to the default\n> + * value of Linux's vm.max_map_count.\n> + */\n> +#define COUNT_MAX (65530)\n\nWhy the parantheses ?\nAnd would a less generic name be better, like\nMAX_UNMAP_COUNT\n\n> +\n> +struct munmap_queue {\n> +\tvoid *start;\n> +\tsize_t length;\n> +};\n> +\n> +void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)\n> +{\n> +\t/*\n> +\t * We can simply discard munmap operations in the queue by\n> +\t * restricting mmap arguments.\n> +\t */\nShould I read this as\nThe munmap queue is only ment to defere read-only mappings.\nAnd that is what Git does at the moment.\n\n\n> +\tif (start != NULL || flags != MAP_PRIVATE || prot != PROT_READ)\n> +\t\tdie(\"invalid usage of mmap\");\n> +\treturn mmap(start, length, prot, flags, fd, offset);\n> +}\n> +\n> +int git_munmap(void *start, size_t length)\n> +{\n> +\tstatic pthread_mutex_t mutex;\n> +\tstatic struct munmap_queue *queue;\n> +\tstatic int count;\n> +\tint i;\n> +\n> +\tpthread_mutex_lock(&mutex);\n> +\tif (!queue)\n> +\t\tqueue = xmalloc(COUNT_MAX * sizeof(struct munmap_queue));\n> +\tqueue[count].start = start;\n> +\tqueue[count].length = length;\n> +\tif (++count == COUNT_MAX) {\n> +\t\tfor (i = 0; i < COUNT_MAX; i++)\n> +\t\t\tmunmap(queue[i].start, queue[i].length);\n> +\t\tcount = 0;\n> +\t}\n> +\tpthread_mutex_unlock(&mutex);\n> +\treturn 0;\n> +}\n> diff --git a/compat/posix.h b/compat/posix.h\n> index 067a00f33b..3fa1218289 100644\n> --- a/compat/posix.h\n> +++ b/compat/posix.h\n> @@ -278,6 +278,13 @@ int git_munmap(void *start, size_t length);\n>  \n>  #include <sys/mman.h>\n>  \n> +#if defined(__APPLE__)\nI think it would be better to have a global Makefile knob here.\nWhich\na) allows to take out this patch once the MacOs kernel is improved\nb) allows to hook in this code for other OS\nSomething like DEFER_MUNMAPS - better suggestions welcome\n> +#define mmap git_mmap\n> +#define munmap git_munmap\n> +void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);\n> +int git_munmap(void *start, size_t length);\n> +#endif\n> +\n>  #endif /* NO_MMAP || USE_WIN32_MMAP */\n>  \n>  #ifndef MAP_FAILED\n> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\n> index edb0fc04ad..5c08f2fe5c 100644\n> --- a/contrib/buildsystems/CMakeLists.txt\n> +++ b/contrib/buildsystems/CMakeLists.txt\n> @@ -271,6 +271,10 @@ if(CMAKE_SYSTEM_NAME STREQUAL \"Windows\")\n>  \t\tcompat/strdup.c)\n>  \tset(NO_UNIX_SOCKETS 1)\n>  \n> +elseif(CMAKE_SYSTEM_NAME STREQUAL \"Darwin\")\n> +\tlist(APPEND compat_SOURCES\n> +\t\tcompat/osxmmap.c)\n> +\n>  elseif(CMAKE_SYSTEM_NAME STREQUAL \"Linux\")\n>  \tadd_compile_definitions(PROCFS_EXECUTABLE_PATH=\"/proc/self/exe\" HAVE_DEV_TTY )\n>  \tlist(APPEND compat_SOURCES unix-socket.c unix-stream-server.c compat/linux/procinfo.c)\n> diff --git a/meson.build b/meson.build\n> index cee9424475..b9b6e731b1 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -1275,6 +1275,8 @@ elif host_machine.system() == 'windows'\n>    else\n>      libgit_sources += 'compat/mingw.c'\n>    endif\n> +elif host_machine.system() == 'darwin'\n> +  libgit_sources += 'compat/osxmmap.c'\n>  endif\n>  \n>  if host_machine.system() == 'linux'\n> \n> base-commit: 4253630c6f07a4bdcc9aa62a50e26a4d466219d1\n> -- \n> gitgitgadget\n> \n"},{"id":"529238","messageId":"20251021080625.GD259661@coredump.intra.peff.net","threadId":"64359","inReplyTo":"pull.1993.git.1760999702581.gitgitgadget@gmail.com","subject":"Re: [PATCH] macOS: queue for munmap operations","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-21T08:06:25Z","receivedAt":"2025-10-21T08:06:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 20, 2025 at 10:35:02PM +0000, Koji Nakamaru via GitGitGadget wrote:\n\n> From: Koji Nakamaru <koji.nakamaru@gree.net>\n> \n> Executing many mmap/munmap calls alternately can cause a huge load on\n> macOS. In order to reduce it, we should temporarily store munmap\n> operations in a queue and process them all at once when the queue is\n> filled. When the program terminates, we can discard any remaining munmap\n> operations as corresponding mmaped regions are automatically reclaimed.\n> \n> Add a queue for munmap operations to perform them all at once.\n> \n> Here are some example timings. On the Linux kernel repository that\n> requires about 1700 mmap/munmap calls:\n> \n>   time git ls-tree -r -l --full-tree 211ddde > /dev/null\n\nWhy is it doing so many mmap calls? Do you have a ton of loose objects?\nWe have to mmap loose objects individually (because they're all in\nseparate files), but each pack only gets a single map (well, there's a\nwindow parameter, but it's 1GB on 64-bit systems, so you should get a\nhandful of maps at most).\n\nIf you run \"git gc\", how does the resulting ls-tree perform? I have only\n27 mmap() calls on my system.\n\nI know that running \"git gc\" is relatively expensive, but it is also\nbringing other optimizations (like the fact that we don't have to open()\nand map each of those files in the first place!).\n\n> On a private repository that requires about 943000 mmap/munmap calls:\n> \n>   time git ls-tree -r -l --full-tree xxxxxxx > /dev/null\n\nDitto here. I'd be curious how well packed the repo is, and how it does\nafter a repack. If it has a very large packfile, you might also try:\n\n  git config core.packedGitWindowSize 4G\n\nor similar (though for just an ls-tree, we should only be looking at\ntree objects, which in general I'd expect to be in a confined area of\nthe packfile; so the 1GB window is probably plenty).\n\n> +int git_munmap(void *start, size_t length)\n> +{\n> +\tstatic pthread_mutex_t mutex;\n> +\tstatic struct munmap_queue *queue;\n> +\tstatic int count;\n> +\tint i;\n> +\n> +\tpthread_mutex_lock(&mutex);\n> +\tif (!queue)\n> +\t\tqueue = xmalloc(COUNT_MAX * sizeof(struct munmap_queue));\n> +\tqueue[count].start = start;\n> +\tqueue[count].length = length;\n> +\tif (++count == COUNT_MAX) {\n> +\t\tfor (i = 0; i < COUNT_MAX; i++)\n> +\t\t\tmunmap(queue[i].start, queue[i].length);\n> +\t\tcount = 0;\n> +\t}\n> +\tpthread_mutex_unlock(&mutex);\n> +\treturn 0;\n> +}\n\nDoes batching those unmaps actually make them faster? Or is it just that\nthe commands you showed did not fill the queue, so we essentially just\nleaked all of those maps until the program exited?\n\nIf the latter, then I'd wonder:\n\n  1. Does this increase memory pressure, since the OS has no idea we're\n     not actually interested in those maps anymore? Some of them can be\n     quite large, if the command is looking at blobs.\n\n  2. How does it perform on a command that actually fills the queue? I\n     guess something like \"git log --raw\" might do it (though if my\n     guesses above are right, you'd need on the order of 64,000 loose\n     trees).\n\n-Peff\n"},{"id":"529343","messageId":"CAOTNsDxoSFTBwaO0Eqr+r0NQOwdA2Fge3CN7JQtnAWEt2PnDew@mail.gmail.com","threadId":"64359","inReplyTo":"20251021080625.GD259661@coredump.intra.peff.net","subject":"Re: [PATCH] macOS: queue for munmap operations","fromName":"Koji Nakamaru","fromEmail":"koji.nakamaru@gree.net","sentAt":"2025-10-22T01:21:32Z","receivedAt":"2025-10-22T01:21:44Z","isPatch":true,"sender":{"key":"koji.nakamaru@gree.net","avatar":"https://avatars.githubusercontent.com/u/2645978?v=4"},"body":"Thank you for pointing out many unusual mmap calls and other details. As\ndiscussed below, the root cause was simply my ~/.gitconfig. This patch\nmay be useful in some rare/edge cases but a somewhat unusual hack, so\nI'm withdrawing it.\n\nOn Tue, Oct 21, 2025 at 5:07 PM Jeff King <peff@peff.net> wrote:\n>\n> On Mon, Oct 20, 2025 at 10:35:02PM +0000, Koji Nakamaru via GitGitGadget wrote:\n>\n> > From: Koji Nakamaru <koji.nakamaru@gree.net>\n> >\n> > Executing many mmap/munmap calls alternately can cause a huge load on\n> > macOS. In order to reduce it, we should temporarily store munmap\n> > operations in a queue and process them all at once when the queue is\n> > filled. When the program terminates, we can discard any remaining munmap\n> > operations as corresponding mmaped regions are automatically reclaimed.\n> >\n> > Add a queue for munmap operations to perform them all at once.\n> >\n> > Here are some example timings. On the Linux kernel repository that\n> > requires about 1700 mmap/munmap calls:\n> >\n> >   time git ls-tree -r -l --full-tree 211ddde > /dev/null\n>\n> Why is it doing so many mmap calls? Do you have a ton of loose objects?\n> We have to mmap loose objects individually (because they're all in\n> separate files), but each pack only gets a single map (well, there's a\n> window parameter, but it's 1GB on 64-bit systems, so you should get a\n> handful of maps at most).\n>\n> If you run \"git gc\", how does the resulting ls-tree perform? I have only\n> 27 mmap() calls on my system.\n>\n> I know that running \"git gc\" is relatively expensive, but it is also\n> bringing other optimizations (like the fact that we don't have to open()\n> and map each of those files in the first place!).\n>\n> > On a private repository that requires about 943000 mmap/munmap calls:\n> >\n> >   time git ls-tree -r -l --full-tree xxxxxxx > /dev/null\n>\n> Ditto here. I'd be curious how well packed the repo is, and how it does\n> after a repack. If it has a very large packfile, you might also try:\n>\n>   git config core.packedGitWindowSize 4G\n>\n> or similar (though for just an ls-tree, we should only be looking at\n> tree objects, which in general I'd expect to be in a confined area of\n> the packfile; so the 1GB window is probably plenty).\n\nFollowing your suggestion, I investigated the number of mmap calls in\nother environments and found much smaller counts. I tracked how\nxmmap_gently() was called in packfile.c and found\nsettings->packed_git_window_size was different between environments. My\n~/.gitconfig defined \"packedGitLimit = 128m\" and this caused many calls.\n\n> > +int git_munmap(void *start, size_t length)\n> > +{\n> > +     static pthread_mutex_t mutex;\n> > +     static struct munmap_queue *queue;\n> > +     static int count;\n> > +     int i;\n> > +\n> > +     pthread_mutex_lock(&mutex);\n> > +     if (!queue)\n> > +             queue = xmalloc(COUNT_MAX * sizeof(struct munmap_queue));\n> > +     queue[count].start = start;\n> > +     queue[count].length = length;\n> > +     if (++count == COUNT_MAX) {\n> > +             for (i = 0; i < COUNT_MAX; i++)\n> > +                     munmap(queue[i].start, queue[i].length);\n> > +             count = 0;\n> > +     }\n> > +     pthread_mutex_unlock(&mutex);\n> > +     return 0;\n> > +}\n>\n> Does batching those unmaps actually make them faster? Or is it just that\n> the commands you showed did not fill the queue, so we essentially just\n> leaked all of those maps until the program exited?\n>\n> If the latter, then I'd wonder:\n>\n>   1. Does this increase memory pressure, since the OS has no idea we're\n>      not actually interested in those maps anymore? Some of them can be\n>      quite large, if the command is looking at blobs.\n>\n>   2. How does it perform on a command that actually fills the queue? I\n>      guess something like \"git log --raw\" might do it (though if my\n>      guesses above are right, you'd need on the order of 64,000 loose\n>      trees).\n\nIn my extreme cases, this batching makes them faster. Queue flushing has\noccurred several times for the private repository case and not occurred\nfor the Linux kernel case. Though I haven't investigated in detail,\nmemory pressure doesn't seem to be critical (and it could also be\npossible to adopt smarter thresholds).\n\nI tested git log --raw for the Linux kernel repository. For reference,\nthe results are shown below:\n\n  without \"packedGitLimit = 128m\":\n\n        mmap    9\n\n        # without batching\n        real    1m3.970s\n        user    1m2.232s\n        sys     0m1.725s\n\n        # with batching\n        real    1m5.991s\n        user    0m58.637s\n        sys     0m4.315s\n\n  with \"packedGitLimit = 128m\":\n\n        mmap    3072538\n\n        # without batching\n        (It took too long so I stopped the execution)\n        real    518m6.928s\n        user    0m41.126s\n        sys     517m24.072s\n\n        # with batching\n        real    2m26.276s\n        user    1m8.495s\n        sys     1m3.230s\n"},{"id":"529344","messageId":"CAOTNsDwFhCR67qx5aOFntOM3oAAXV4NDMfy_LC5VAYMu-o3uXg@mail.gmail.com","threadId":"64359","inReplyTo":"20251021062621.GA370@tb-raspi4","subject":"Re: [PATCH] macOS: queue for munmap operations","fromName":"Koji Nakamaru","fromEmail":"koji.nakamaru@gree.net","sentAt":"2025-10-22T01:22:12Z","receivedAt":"2025-10-22T01:22:24Z","isPatch":true,"sender":{"key":"koji.nakamaru@gree.net","avatar":"https://avatars.githubusercontent.com/u/2645978?v=4"},"body":"Thank you for detailed suggestions. As I discussed in another thread,\nthe root cause of many mmap/munmap calls was simply my ~/.gitconfig, so\nI'm withdrawing this patch. I'll answer some of your comments below.\n\nOn Tue, Oct 21, 2025 at 3:26 PM Torsten Bögershausen <tboegi@web.de> wrote:\n>\n> Some comments inline, all up to improvements\n>\n> On Mon, Oct 20, 2025 at 10:35:02PM +0000, Koji Nakamaru via GitGitGadget wrote:\n> > From: Koji Nakamaru <koji.nakamaru@gree.net>\n> >\n> > Executing many mmap/munmap calls alternately can cause a huge load on\n> > macOS. In order to reduce it, we should temporarily store munmap\n> > operations in a queue and process them all at once when the queue is\n> > filled. When the program terminates, we can discard any remaining munmap\n> > operations as corresponding mmaped regions are automatically reclaimed.\n> >\n> > Add a queue for munmap operations to perform them all at once.\n> >\n>\n> Suggestions for rewording:\n> In order to reduce the peak load store all munmap operations in a queue.\n> Process them all at once (and more efficient) when the queue is filled.\n> The queue may be ignored when the git process terminates. The operating\n> system will do all munmap() when the process exits.\n\nThank you, it is much clear.\n\n> > Here are some example timings. On the Linux kernel repository that\n> > requires about 1700 mmap/munmap calls:\n> >\n> >   time git ls-tree -r -l --full-tree 211ddde > /dev/null\n> >\n> >   Before:\n> >         real    0m2.083s\n> >         user    0m0.201s\n> >         sys     0m1.873s\n> >\n> >   After:\n> >         real    0m0.243s\n> >         user    0m0.179s\n> >         sys     0m0.052s\n> >\n> > On a private repository that requires about 943000 mmap/munmap calls:\n> >\n> >   time git ls-tree -r -l --full-tree xxxxxxx > /dev/null\n> >\n> >   Before:\n> >         real    27m15.138s\n> >         user    0m5.084s\n> >         sys     27m9.636s\n> >\n> >   After:\n> >         real    0m24.209s\n> >         user    0m3.055s\n> >         sys     0m21.123s\n> >\n> > Signed-off-by: Koji Nakamaru <koji.nakamaru@gree.net>\n> > ---\n> >     macOS: queue for munmap operations\n> >\n> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1993%2FKojiNakamaru%2Ffeature%2Fosx-queued-munmap-v1\n> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1993/KojiNakamaru/feature/osx-queued-munmap-v1\n> > Pull-Request: https://github.com/gitgitgadget/git/pull/1993\n> >\n> >  Makefile                            |  1 +\n> >  compat/osxmmap.c                    | 49 +++++++++++++++++++++++++++++\n> >  compat/posix.h                      |  7 +++++\n> >  contrib/buildsystems/CMakeLists.txt |  4 +++\n> >  meson.build                         |  2 ++\n> >  5 files changed, 63 insertions(+)\n> >  create mode 100644 compat/osxmmap.c\n> >\n> > diff --git a/Makefile b/Makefile\n> > index f79c905bdc..058bc83753 100644\n> > --- a/Makefile\n> > +++ b/Makefile\n> > @@ -1654,6 +1654,7 @@ ifeq ($(uname_S),Darwin)\n> >               COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO\n> >          endif\n> >       PTHREAD_LIBS =\n> > +     COMPAT_OBJS += compat/osxmmap.o\n> >  endif\n> >\n> >  ifdef NO_LIBGEN_H\n> > diff --git a/compat/osxmmap.c b/compat/osxmmap.c\n> > new file mode 100644\n> > index 0000000000..5f9cf633ca\n> > --- /dev/null\n> > +++ b/compat/osxmmap.c\n> > @@ -0,0 +1,49 @@\n> > +#include <pthread.h>\n> > +#include \"../git-compat-util.h\"\n> > +/* We need original mmap/munmap here. */\n> > +#undef mmap\n> > +#undef munmap\n> > +\n> > +/*\n> > + * OSX doesn't have any specific setting like Linux's vm.max_map_count,\n> > + * so COUNT_MAX can be any large number. We here set it to the default\n> > + * value of Linux's vm.max_map_count.\n> > + */\n> > +#define COUNT_MAX (65530)\n>\n> Why the parantheses ?\n> And would a less generic name be better, like\n> MAX_UNMAP_COUNT\n\nThe parentheses are not required but I prefer them as discussed in [1].\nI agree MAX_UNMAP_COUNT is more clear.\n\n> > +\n> > +struct munmap_queue {\n> > +     void *start;\n> > +     size_t length;\n> > +};\n> > +\n> > +void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)\n> > +{\n> > +     /*\n> > +      * We can simply discard munmap operations in the queue by\n> > +      * restricting mmap arguments.\n> > +      */\n> Should I read this as\n> The munmap queue is only ment to defere read-only mappings.\n> And that is what Git does at the moment.\n\nYes. This part is actually borrowed from compat/mmap.c and I've also\nverified that the predicate is valid by searching all mmap calls.\n\n> > +     if (start != NULL || flags != MAP_PRIVATE || prot != PROT_READ)\n> > +             die(\"invalid usage of mmap\");\n> > +     return mmap(start, length, prot, flags, fd, offset);\n> > +}\n> > +\n> > +int git_munmap(void *start, size_t length)\n> > +{\n> > +     static pthread_mutex_t mutex;\n> > +     static struct munmap_queue *queue;\n> > +     static int count;\n> > +     int i;\n> > +\n> > +     pthread_mutex_lock(&mutex);\n> > +     if (!queue)\n> > +             queue = xmalloc(COUNT_MAX * sizeof(struct munmap_queue));\n> > +     queue[count].start = start;\n> > +     queue[count].length = length;\n> > +     if (++count == COUNT_MAX) {\n> > +             for (i = 0; i < COUNT_MAX; i++)\n> > +                     munmap(queue[i].start, queue[i].length);\n> > +             count = 0;\n> > +     }\n> > +     pthread_mutex_unlock(&mutex);\n> > +     return 0;\n> > +}\n> > diff --git a/compat/posix.h b/compat/posix.h\n> > index 067a00f33b..3fa1218289 100644\n> > --- a/compat/posix.h\n> > +++ b/compat/posix.h\n> > @@ -278,6 +278,13 @@ int git_munmap(void *start, size_t length);\n> >\n> >  #include <sys/mman.h>\n> >\n> > +#if defined(__APPLE__)\n> I think it would be better to have a global Makefile knob here.\n> Which\n> a) allows to take out this patch once the MacOs kernel is improved\n> b) allows to hook in this code for other OS\n> Something like DEFER_MUNMAPS - better suggestions welcome\n\nI followed your suggestion and adjusted code and Makefile, etc. (locally)\n\n> > [snip]\n\n[1] https://stackoverflow.com/questions/9081479/is-there-a-good-reason-for-always-enclosing-a-define-in-parentheses-in-c\n"},{"id":"529399","messageId":"20251022090539.GA853931@coredump.intra.peff.net","threadId":"64359","inReplyTo":"CAOTNsDxoSFTBwaO0Eqr+r0NQOwdA2Fge3CN7JQtnAWEt2PnDew@mail.gmail.com","subject":"Re: [PATCH] macOS: queue for munmap operations","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-22T09:05:39Z","receivedAt":"2025-10-22T09:05:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 22, 2025 at 10:21:32AM +0900, Koji Nakamaru wrote:\n\n> > Ditto here. I'd be curious how well packed the repo is, and how it does\n> > after a repack. If it has a very large packfile, you might also try:\n> >\n> >   git config core.packedGitWindowSize 4G\n> >\n> > or similar (though for just an ls-tree, we should only be looking at\n> > tree objects, which in general I'd expect to be in a confined area of\n> > the packfile; so the 1GB window is probably plenty).\n> \n> Following your suggestion, I investigated the number of mmap calls in\n> other environments and found much smaller counts. I tracked how\n> xmmap_gently() was called in packfile.c and found\n> settings->packed_git_window_size was different between environments. My\n> ~/.gitconfig defined \"packedGitLimit = 128m\" and this caused many calls.\n\nAh, very interesting. Yes, I think that helps explain why there were so\nmany mmap calls. I don't think there's a good reason to lower that\nnumber in general, assuming the OS is reasonably good at dropping mapped\npages from RAM when there's memory pressure.\n\n> In my extreme cases, this batching makes them faster. Queue flushing has\n> occurred several times for the private repository case and not occurred\n> for the Linux kernel case. Though I haven't investigated in detail,\n> memory pressure doesn't seem to be critical (and it could also be\n> possible to adopt smarter thresholds).\n\nOK, that's quite interesting that batching makes such a difference. I\nguess somebody with more knowledge of macOS kernel internals could\nprobably explain it. Though it sounds like your problem was sufficiently\nsolved by dropping the extra config, it's a good fact for us to know\nabout in general.\n\n-Peff\n"}]}