forked from git/git
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
parallel-checkout: auto-enable parallelism on NFS
Parallel checkout is usually faster than the default sequential version when writing to SSD or to NFS mounts. For NFS, this is true even when the client and the server are both running on single-core machines, and regardless of the NFS version. Below are the mean runtimes and standard deviations for 5 cold-cache executions of a local linux-v5.8 clone, on Linux, with increasing number of checkout workers. The NFS client, where Git was invoked, is an Amazon EC2 c5n.large instance, and the NFS server is a m6g.large instance. Both have two vCPUs, but I disabled the additional core, to simulate single-core machines. nfs 3.0 nfs 4.0 nfs 4.1 1: 183.708 s ± 3.290 s 205.851 s ± 0.844 s 217.317 s ± 3.047 s 2: 130.510 s ± 3.917 s 139.124 s ± 0.772 s 142.963 s ± 0.765 s 4: 89.611 s ± 1.032 s 102.701 s ± 1.665 s 94.728 s ± 1.014 s 8: 68.097 s ± 0.820 s 104.914 s ± 1.239 s 69.359 s ± 0.619 s 16: 63.999 s ± 0.820 s 104.808 s ± 2.279 s 64.843 s ± 0.587 s 32: 62.316 s ± 2.095 s 102.105 s ± 1.537 s 64.122 s ± 0.374 s 64: 63.699 s ± 0.841 s 103.103 s ± 1.319 s 63.532 s ± 0.734 s The parallel version was also faster on small checkouts. Below are the benchmark numbers for a local clone of the 'bat' repository, in the same environment of the previous test but with 15 repetitions. The version of 'bat' cloned (v0.16.0) has 251 files, which correspond to about 3MB. (The default threshold to enable parallelism is 100 files). nfs 3.0 nfs 4.0 nfs 4.1 1: 0.853 s ± 0.080 s 0.814 s ± 0.020 s 0.876 s ± 0.065 s 2: 0.671 s ± 0.020 s 0.702 s ± 0.030 s 0.705 s ± 0.030 s 4: 0.530 s ± 0.024 s 0.595 s ± 0.020 s 0.570 s ± 0.030 s 8: 0.470 s ± 0.033 s 0.609 s ± 0.025 s 0.510 s ± 0.031 s 16: 0.469 s ± 0.037 s 0.616 s ± 0.022 s 0.513 s ± 0.030 s 32: 0.487 s ± 0.030 s 0.639 s ± 0.018 s 0.527 s ± 0.028 s 64: 0.520 s ± 0.022 s 0.680 s ± 0.028 s 0.562 s ± 0.026 s From these results, it seems that it is always advantageous to use parallel-checkout on NFS, even on single-core machines and for considerably small numbers of files. So, seeking to provide users with the best performance by default, let's attempt to detect the file system type and auto-enable parallelism on NFS (only when `checkout.workers` is not already set). From the above numbers, 16 workers seem to be a good default. If detection fails, we just fall back to the regular sequential code. Note: inferring the type of a file system is a platform-specific problem. So the auto-detection is currently only implemented on Linux, where we already verified that 16 workers usually brings the best performance. Also, there are a number of ways to query the mounts table on Linux, but we choose to manually read the /etc/mtab file. Other alternatives that were discarded include: * statfs(): (non-POSIX) marked as deprecated. * getmntent(): (non-POSIX) discarded because that are implementation differences among the different libc's. For example, the glibc version unescapes the mount paths, whereas musl leaves them as they appear on the mount table. * statvfs(): it's in POSIX, but doesn't provide file system type. * libmount: adds a new dependency. The function unscape_mtab_path() was copied from misc/mntent_r.c:decode_name() in glibc commit 75a193b7611bade31a150dfcc528b973e3d46231, and adapted to use Git's internal API and coding style. The original implementation is licensed under LGPLv2.1. According to [1], it can be relicensed here to GPLv2. Finally, two tests were added to make sure that the file system detection is correctly working, and that the sequential code is used for non-NFS checkouts. [1]: https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
- Loading branch information
1 parent
d8c8ae5
commit 2e2c787
Showing
9 changed files
with
215 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters