config: control core.packedGitLimit value
commit86d5b3f87f87b92b9fe5054615775d2747118ea7
authorKyle J. McKay <mackyle@gmail.com>
Wed, 4 Mar 2020 11:09:27 +0000 (4 04:09 -0700)
committerKyle J. McKay <mackyle@gmail.com>
Wed, 4 Mar 2020 11:09:27 +0000 (4 04:09 -0700)
tree2b2c2262419a31d9db8cea703a283e41d0e7a22d
parentc545ef954970e73cecefa1538c0cb3ebb4f63b29
config: control core.packedGitLimit value

The Git configuration value for `core.packedGitLimit` defaults to
either 256m on a 32-bit platform or 8g on a 64-bit platform.

Imagine that 8 simultaneously running `git` processes are attempting
to access an 8 gigabyte (or more) pack file on a 64-bit platform.

That means that 64 gigabytes of mmap'd files will be active (unless
the different processes are accessing the same pack file in which
case they can share the map since it will be read-only).

In such a scenario, a system with less than 64g of available memory
will end up in a swapping situation.

If the system's memory size plus the system's fixed maximum swap
space is less than 64g, then it will likely experience some "unwanted
behavior" at some point.

Attempt to address this 64-bit platform issue by always setting
`core.packedGitLimit` to the value that would be used for a
32-bit platform (i.e. "256m").

Since 32-bit platforms have no difficulty dealing with pack files
much larger than "256m" (where "256m" is the default value for
`core.packedGitLimit`), this change will not affect access to
large pack files.

Something similar has previously already been done for the value
of the `core.packedGitWindowSize` to great benefit.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
bin/git-shell-verify
gitweb/gitweb_config.perl
shlib.sh