{"thread":{"id":"6229","subject":"[PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.","startedAt":"2007-01-05T03:28:08Z","lastAt":"2007-01-05T06:01:20Z","messageCount":2,"participants":["Shawn O. Pearce","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"30858","messageId":"20070105032808.GA14247@spearce.org","threadId":"6229","inReplyTo":null,"subject":"[PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-05T03:28:08Z","receivedAt":"2007-01-05T03:28:08Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"If we have a 64 bit address space we can easily afford to commit\na larger amount of virtual address space to pack file access.\nSo on these platforms we should increase the default settings of\ncore.packedGit{Limit,WindowSize} to something that will better\nhandle very large projects.\n\nThanks to Andy Whitcroft for pointing out that we can safely\nincrease these defaults on such systems.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n Documentation/config.txt |   16 ++++++++++------\n git-compat-util.h        |   10 ++++++++--\n 2 files changed, 18 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex e4ee52f..b4aae0d 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -125,9 +125,12 @@ core.packedGitWindowSize::\n \tmore quickly.  Smaller window sizes will negatively affect\n \tperformance due to increased calls to the operating system's\n \tmemory manager, but may improve performance when accessing\n-\ta large number of large pack files.  Default is 32 MiB,\n-\twhich should be reasonable for all users/operating systems.\n-\tYou probably do not need to adjust this value.\n+\ta large number of large pack files.\n++\n+Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32\n+MiB on 32 bit platforms and 1 GiB on 64 bit platforms.  This should\n+be reasonable for all users/operating systems.  You probably do\n+not need to adjust this value.\n +\n Common unit suffixes of 'k', 'm', or 'g' are supported.\n \n@@ -136,9 +139,10 @@ core.packedGitLimit::\n \tfrom pack files.  If Git needs to access more than this many\n \tbytes at once to complete an operation it will unmap existing\n \tregions to reclaim virtual address space within the process.\n-\tDefault is 256 MiB, which should be reasonable for all\n-\tusers/operating systems, except on the largest projects.\n-\tYou probably do not need to adjust this value.\n++\n+Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.\n+This should be reasonable for all users/operating systems, except on\n+the largest projects.  You probably do not need to adjust this value.\n +\n Common unit suffixes of 'k', 'm', or 'g' are supported.\n \ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex f243b86..55456da 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -97,11 +97,17 @@ extern int git_munmap(void *start, size_t length);\n #else /* NO_MMAP */\n \n #include <sys/mman.h>\n-#define DEFAULT_PACKED_GIT_WINDOW_SIZE (32 * 1024 * 1024)\n+#define DEFAULT_PACKED_GIT_WINDOW_SIZE \\\n+\t(sizeof(void*) >= 8 \\\n+\t\t?  1 * 1024 * 1024 * 1024 \\\n+\t\t: 32 * 1024 * 1024)\n \n #endif /* NO_MMAP */\n \n-#define DEFAULT_PACKED_GIT_LIMIT (256 * 1024 * 1024)\n+#define DEFAULT_PACKED_GIT_LIMIT \\\n+\t(sizeof(void*) >= 8 \\\n+\t\t?   8 * 1024 * 1024 * 1024 \\\n+\t\t: 256 * 1024 * 1024)\n \n #ifdef NO_SETENV\n #define setenv gitsetenv\n-- \n1.5.0.rc0.gce9e\n"},{"id":"30860","messageId":"7v4pr6j9lb.fsf@assigned-by-dhcp.cox.net","threadId":"6229","inReplyTo":"20070105032808.GA14247@spearce.org","subject":"Re: [PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T06:01:20Z","receivedAt":"2007-01-05T06:01:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> If we have a 64 bit address space we can easily afford to commit\n> a larger amount of virtual address space to pack file access.\n> So on these platforms we should increase the default settings of\n> core.packedGit{Limit,WindowSize} to something that will better\n> handle very large projects.\n\nHmmmm.  What's the reasoning behind this?\n\nWe have more than enough virtual memory anyway, we do not bother\nwith our own mmap limit -- we will let the operating system\nworry about it.\n\nIf that is the reasoning, I have a feeling that we might want to\nbe even more agressive.  If you have a 1.5GB pack, wouldn't you\nrather map the whole thing in a single window, instead of\nsplitting that into two?\n\nCurrently we are limited (by pack offset) to 4GB per pack, so\nraising the window max to 4GB might make sense.\n\nOn the total size of vm space, I am wondering what would happen\nif we make this unbounded.  You certainly notice mmap() failure\nand fall back to recycle other windows even when your total\nusage is under the limit, don't you?  Your later patches in the\nseries even unmap the mapped but unused window lazily to make\nroom for xmalloc() and friends, so I suspect it might even make\nit simpler not to have this limit especially on larger systems.\n"}]}