Cloning the Linux kernel in under a minute

[Byron]

Cloning the Linux kernel in under a minute

TLDR

Using gitoxide with default settings, we can now clone the linux kernel repository (receiving a pack, resolving it and a checkout of the working tree) in 43s using all cores of an M1 Pro. Canonical git (with default settings) finishes the same clone in 115s, making gitoxide ~2.7x faster.

On a 16 core AMD workstation we can achieve the same clone in 30s, while canonical git takes 141s. Putting it into a number, gitoxide is able to outperform git by a factor of ~4.8.

This will make a difference on CI and locally saving time and memory, when it's ready for prime time early next year.

For reproduction, please see the Reproduction section at the bottom of the document, or keep going for all the details.

The Results

We see that gix is ~1.4x faster than git on a single core, and ~2.6x faster with all cores of the test system.
It's notable that the default settings of gix compared to the ones by git allow it to reach ~2.7x of its speed as it will use all cores of the test system (M1 Pro).

Please note that 28s of the 43s of the best result obtained with gix are transfer costs alone, which bottlenecks on ZLIB decompression performance on the client side. If that wasn't the case, we could see gigabytes per second in transfer speeds, as the server-side git process isn't very busy at ~10% of a CPU.

Raw benchmark results

Command	Mean [s]	Min [s]	Max [s]	Relative
gix -c pack.threads=1 -c checkout.workers=1 clone ./linux ./linux-clone	117.558 ± 0.518	117.192	117.925	2.76 ± 0.03
git -c pack.threads=1 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone	159.987 ± 0.810	159.415	160.560	3.75 ± 0.04
gix -c pack.threads=1 -c checkout.workers=4 clone ./linux ./linux-clone	112.942 ± 1.438	111.926	113.959	2.65 ± 0.04
git -c pack.threads=1 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	155.043 ± 2.399	153.347	156.739	3.63 ± 0.06
gix -c pack.threads=3 -c checkout.workers=1 clone ./linux ./linux-clone	66.564 ± 1.152	65.750	67.379	1.56 ± 0.03
git -c pack.threads=3 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone	115.257 ± 1.584	114.137	116.377	2.70 ± 0.04
gix -c pack.threads=3 -c checkout.workers=4 clone ./linux ./linux-clone	60.748 ± 0.779	60.197	61.299	1.42 ± 0.02
git -c pack.threads=3 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	106.404 ± 2.039	104.962	107.846	2.49 ± 0.05
gix -c pack.threads=10 -c checkout.workers=1 clone ./linux ./linux-clone	48.694 ± 0.359	48.440	48.947	1.14 ± 0.01
git -c pack.threads=10 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone	116.438 ± 0.783	115.884	116.991	2.73 ± 0.03
gix -c pack.threads=10 -c checkout.workers=4 clone ./linux ./linux-clone	42.663 ± 0.358	42.410	42.916	1.00
git -c pack.threads=10 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	110.624 ± 1.162	109.802	111.445	2.59 ± 0.03

Bonus Round: Amd64 (or how to clone in ~30s)

The test system at hand is a custom built PC with an AMD Ryzen™ 9 3950X, 64GB 3200MHz DDR4, M.2 PCIE-4 NVME SDD running Fedora 36 workstation.

It's notable how much better a standard build of gix performs compared to a standard build of git with just a single thread being 2.9x faster. With default settings, gix using all cores outperforms git by a factor of ~4.8x which effectively uses only 3 cores.

Note that even though gitoxide scales nicely with additional cores, the absolute time saved has diminishing returns due to the pack transfer already taking ~23s, while the checkout takes 1.7s and is limited by the SSD + filesystem.

Raw benchmark results

Command	Mean [s]	Min [s]	Max [s]	Relative
gix -c pack.threads=1 -c checkout.workers=4 clone ./linux ./linux-clone	93.977 ± 0.850	93.376	94.578	3.10 ± 0.04
git -c pack.threads=1 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	272.624 ± 0.218	272.469	272.778	8.99 ± 0.10
gix -c pack.threads=3 -c checkout.workers=4 clone ./linux ./linux-clone	49.767 ± 0.069	49.718	49.816	1.64 ± 0.02
git -c pack.threads=3 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	142.888 ± 0.078	142.833	142.944	4.71 ± 0.05
gix -c pack.threads=8 -c checkout.workers=4 clone ./linux ./linux-clone	35.940 ± 0.059	35.898	35.981	1.19 ± 0.01
git -c pack.threads=8 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	122.182 ± 0.555	121.790	122.574	4.03 ± 0.05
gix -c pack.threads=16 -c checkout.workers=4 clone ./linux ./linux-clone	32.704 ± 1.369	31.735	33.672	1.08 ± 0.05
git -c pack.threads=16 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	120.722 ± 1.226	119.855	121.589	3.98 ± 0.06
gix -c pack.threads=32 -c checkout.workers=4 clone ./linux ./linux-clone	30.317 ± 0.331	30.083	30.551	1.00
git -c pack.threads=32 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone	127.546 ± 1.743	126.313	128.779	4.21 ± 0.07

Breakdown of clone time with default settings

> gix -v clone ./linux ./linux-clone
read pack done 2.6GB in 23.10s (114.4MB/s)                                                                                                                         
 indexing 18186718 objects where resolved into 9093359 objects during thin-pack resolution                                                                         
 indexing done 9.1M objects in 22.25s (408.8k objects/s)                                                                                                           
decompressing done 6.3GB in 22.25s (283.9MB/s)                                                                                                                     
    Resolving done 9.1M objects in 3.16s (2.9M objects/s)                                                                                                          
    Decoding done 118.8GB in 3.16s (37.6GB/s)                                                                                                                     
writing index file done 278.6MB in 0.41s (672.1MB/s)                                                                                                               
 create index file done 9.1M objects in 28.88s (314.9k objects/s)                                                                                                  
    checkout done 78.0k files in 1.51s (51.6k files/s)                                                                                                       
    writing done 1.3GB in 1.51s (845.0MB/s)     

Note: It's fascinating that this CPU can decode 37.6GB of objects per second.

The times shown here may overlap due to parallel execution and do not add up to the total runtime (30 seconds).

Bonus Round: Memory Consumption

All this performance offered by gix might come at the expense of memory consumption, and here are two measurements created by hand with default options to represent typical usage.

	peak memory [MB]	command-line
gix	1173	/usr/bin/time -lp gix -v clone ./linux ./linux-clone
git	~2160	/usr/bin/time -lp git clone file://$PWD/linux ./linux-clone

Note: git launches a sub-process to do the work of receiving a pack which isn’t visible with /usr/bin/time. The sub-process peaks at 2.16GB of real memory, as manually observed in ‘Activity Monitor’. This value does not include connectivity checks as they are disabled in this custom build.

gix can do the same work faster and with nearly half the memory.

Raw benchmark results

❯ /usr/bin/time -lp gix -v clone ./linux ./linux-clone
 20:18:48 read pack done 3.8GB in 37.46s (102.1MB/s)
 20:18:48  indexing 17949636 objects where resolved into 8974818 objects during thin-pack resolution
 20:18:48  indexing done 9.0M objects in 36.24s (247.7k objects/s)
 20:18:48 decompressing done 8.2GB in 36.24s (227.0MB/s)
 20:18:59     Resolving done 9.0M objects in 10.95s (819.4k objects/s)
 20:18:59      Decoding done 116.5GB in 10.95s (10.6GB/s)
 20:19:01 writing index file done 302.2MB in 0.42s (721.3MB/s)
 20:19:01  create index file done 9.0M objects in 49.24s (182.3k objects/s)
 20:19:04           checkout done 78.0k files in 2.61s (29.9k files/s)
 20:19:04            writing done 1.3GB in 2.61s (490.3MB/s)
+refs/heads/*:refs/remotes/origin/*
        94f0b2d4a1d0c52035aef425da5e022bd2cb1c71 refs/heads/linux-checkout -> refs/remotes/origin/linux-checkout [new]
        94f0b2d4a1d0c52035aef425da5e022bd2cb1c71 refs/heads/linux-checkout-2 -> refs/remotes/origin/linux-checkout-2 [new]
        94f0b2d4a1d0c52035aef425da5e022bd2cb1c71 refs/heads/linux-checkout-3 -> refs/remotes/origin/linux-checkout-3 [new]
        df0cc57e057f18e44dac8e6c18aba47ab53202f9 refs/heads/linux-checkout-4 -> refs/remotes/origin/linux-checkout-4 [new]
        dcf8e5633e2e69ad60b730ab5905608b756a032f refs/heads/master -> refs/remotes/origin/master [new]
include/uapi/linux/netfilter/xt_connmark.h: collision (AlreadyExists)
include/uapi/linux/netfilter/xt_dscp.h: collision (AlreadyExists)
include/uapi/linux/netfilter/xt_mark.h: collision (AlreadyExists)
include/uapi/linux/netfilter/xt_rateest.h: collision (AlreadyExists)
include/uapi/linux/netfilter/xt_tcpmss.h: collision (AlreadyExists)
include/uapi/linux/netfilter_ipv4/ipt_ecn.h: collision (AlreadyExists)
include/uapi/linux/netfilter_ipv4/ipt_ttl.h: collision (AlreadyExists)
include/uapi/linux/netfilter_ipv6/ip6t_hl.h: collision (AlreadyExists)
net/netfilter/xt_dscp.c: collision (AlreadyExists)
net/netfilter/xt_hl.c: collision (AlreadyExists)
net/netfilter/xt_rateest.c: collision (AlreadyExists)
net/netfilter/xt_tcpmss.c: collision (AlreadyExists)
tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus: collision (AlreadyExists)
Error: One or more errors occurred - checkout is incomplete: encountered 13 collision(s)
real 53.22
user 142.87
sys 18.52
          4934270976  maximum resident set size
                   0  average shared memory size
                   0  average unshared data size
                   0  average unshared stack size
              783101  page reclaims
               19631  page faults
                   0  swaps
                   0  block input operations
                   0  block output operations
                   0  messages sent
                   0  messages received
                   1  signals received
              125456  voluntary context switches
              349316  involuntary context switches
        811421925312  instructions retired
        461348252772  cycles elapsed
          1172772736  peak memory footprint

Bonus: Racing git

See how gix tries to beat git in cloning the Linux kernel over the network on a beefy machine.

Conclusions

gitoxide has the potential to substantially speed up clone operations by scaling with today's multi-core CPUs, and it will keep scaling with every new hardware generation. git currently does not scale well with cores and it will be a major undertaking to change that.

Special Thanks

I am grateful for the help of Pascal Kuthe who generously gave his time to review this post and improve it tremendously in the process. He is also responsible for the graphs, making it so much more accessible, and prettier too. Thank you!

FAQ

Can I use it now?

Yes, if the checkout does not involve submodules or rely on filters (like line-feed conversions or git-lfs). These features are expected to be fully implemented early next year (2023).

Can I post my own results here?

Yes, please, test it on your 128core machine to see how low these numbers can go. Please note though that the runtime is dominated by transfer time which clocks in at about 28s.

How can gitoxide be that fast?

gitoxide has been built from the ground up for performance. It doesn't use the heap generously and reuses allocations where ever feasible.

On top of that, the most time-consuming stage of a clone, the pack index creation, is algorithmically optimal such that a data structure is built to know exactly which delta to apply on which base, effectively representing the delta-tree in memory. With it one can resolve the pack, that is decompress every object, without requiring any other caches and without wasting any work or memory.

Thanks to the Rust ecosystem, it's easy to get the best performing ZLIB implementation and the fastest SHA1 hash implementation for most platforms, which affects this workload a lot. With the right hardware, this step can now scale linearly with each core, yielding ~38GB/s decompression speed on a recent AMD Ryzen.

All of the above wouldn't be possible without Rust, the key-enabler for all optimizations and fearless concurrency.

Why is canonical git slower on an AMD workstation than on a M1 MacBook?

We found this surprsing as well, but after rerunning the benchmarks multiple times, the results turned out to be consistent.
Some component of canonical git is probably much better optimized on Aarch64 to greatly improve performance.
As git does not scale nearly as well as gitoxide across multiple cores, it's not able to capitalize on the higher core count, which increases the gap even further.

Reproduction

The test setup

We will use the Linux kernel as a benchmark. To get a reliable benchmark we exclude the network by using a local copy of the repository. To get clone performance similar to the one of an optimized server we also enable some caches.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git checkout v6.0-rc3
git repack --write-bitmap-index -a

Note: The size of the pack affects the transfer time linearly, and these benchmarks worked with a 2.65GB pack. Your pack might be larger, affecting transfer times negatively.

Now we can direct our git clients, gix and git, towards the local copy and perform a clone using the same machinery that would normally run over the network.

By default git will just hardlink the relevant files when performing local clones. However we can nudge it to perform a proper clone by using git clone file://./linux linux-clone. gitoxide does currently not utilize hardlinking and just calling gix clone ./linux linux-clone is enough.

Since git now treats the clone as 'remote' with limited trust, it would force a connectivity check on the received data to assure it's not garbage which takes time and (a lot of) memory, so we disable it with the following patch on top of this commit.

diff --git a/builtin/clone.c b/builtin/clone.c
index 547d6464b3..7f5fd75608 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -1355,7 +1355,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 
 	update_remote_refs(refs, mapped_refs, remote_head_points_at,
 			   branch_top.buf, reflog_msg.buf, transport,
-			   !is_local);
+			   /* !is_local */ 0);
 
 	update_head(our_head_points_at, remote_head, unborn_head, reflog_msg.buf);

The patch can be applied with git apply <PATCH_FILE> and with that, we get:

make # add -j10 for using 10 cores
./git --version
./git version 2.38.1.381.gc03801e19c.dirty

Note: Support for connectivity checks will be implemented in gitoxide in the future.

The experimental gitoxide CLI gix can be installed using cargo:

cargo install --git https://github.com/Byron/gitoxide --rev 400e05841c5306e1b47f719ed8615e5297edb597 gitoxide

Understanding Performance Options

The unit of data transport in git is a pack which is a set of highly compressed objects. Together these objects make up the object graph of the repository which contains all commits and files tracked by git.
When cloning, a pack with all objects required by the client is created by the server and streamed to the client.

This process can be broken down into the following steps:

1. create packs that contain all required objects on the server side - we have created caches to accelerate this
2. transfer packs from the server to the client - we exchanged the network with a pipe, maximising transfer speed
3. create a pack index from the transferred pack on the client side - pack.threads determines how fast this goes, defaulting to 3 for git and 'all-CPUs' for gix
4. populate the client side worktree by checking out files - checkout.workers affects the performance, which defaults to 3 for git and all-CPUs for gix

Thus we have two parameters that affect the two last stages of the clone operation, with the last stage being the fastest one, and the second to last being the one that that has the biggest impact on performance.

Gathering Results

We use hyperfine for obtaining the results and run it with:

hyperfine --export-csv results.csv --export-markdown results.md --export-json results.json -M 2  -p 'rm -Rf ./linux-clone' -L workers 1,4 -L threads 1,3,10 -i 'gix -c pack.threads={threads} -c checkout.workers={workers} clone ./linux ./linux-clone' 'git -c pack.threads={threads} -c checkout.workers={workers} clone file://$PWD/linux ./linux-clone'

Note that the checkout is done onto an actual disk (SSD) to represent typical usage.

Our parameters have been chosen so that they reflect typical usage:

• threads=1
  • single-threaded performance can be most optimal as there is no scheduling overhead. In theory, both binaries could be equal here as parallelisation in C is hard to implement.
• threads=3
  • the default for git if the host has that many CPUs. It's chosen because it's known that higher numbers yield greatly diminished returns or are even reducing performance due to lock contention.
• threads=10
  • The amount of cores in my machine, and thus the highest reasonable value here.
• workers=1
  • The default for git, meaning only one file will be written at a time.
• workers=4
  • The best-performing value for my system, beyond which there are no improvements, but also no performance reduction both for gix or git.

Detailed test data

Output of test runs

❯ hyperfine --export-csv results.csv --export-markdown results.md --export-json results.json -M 2  -p 'rm -Rf ./linux-clone' -L workers 1,4 -L threads 1,3,10 -i 'gix -c pack.threads={threads} -c checkout.workers={workers} clone ./linux ./linux-clone' 'git -c pack.threads={threads} -c checkout.workers={workers} clone file://$PWD/linux ./linux-clone'
Benchmark 1: gix -c pack.threads=1 -c checkout.workers=1 clone ./linux ./linux-clone
  Time (mean ± σ):     137.598 s ±  4.445 s    [User: 127.318 s, System: 10.467 s]
  Range (min … max):   134.455 s … 140.741 s    2 runs

  Warning: Ignoring non-zero exit code.

Benchmark 2: git -c pack.threads=1 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone
  Time (mean ± σ):     189.405 s ±  4.407 s    [User: 165.152 s, System: 23.842 s]
  Range (min … max):   186.289 s … 192.521 s    2 runs

Benchmark 3: gix -c pack.threads=1 -c checkout.workers=4 clone ./linux ./linux-clone
  Time (mean ± σ):     132.837 s ±  1.121 s    [User: 127.406 s, System: 14.716 s]
  Range (min … max):   132.044 s … 133.630 s    2 runs

  Warning: Ignoring non-zero exit code.

Benchmark 4: git -c pack.threads=1 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone
  Time (mean ± σ):     188.010 s ±  2.676 s    [User: 165.918 s, System: 25.163 s]
  Range (min … max):   186.117 s … 189.902 s    2 runs

Benchmark 5: gix -c pack.threads=3 -c checkout.workers=1 clone ./linux ./linux-clone
  Time (mean ± σ):     79.076 s ±  2.085 s    [User: 131.510 s, System: 11.938 s]
  Range (min … max):   77.602 s … 80.550 s    2 runs

  Warning: Ignoring non-zero exit code.

Benchmark 6: git -c pack.threads=3 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone
  Time (mean ± σ):     134.325 s ±  6.173 s    [User: 177.226 s, System: 43.412 s]
  Range (min … max):   129.960 s … 138.690 s    2 runs

Benchmark 7: gix -c pack.threads=3 -c checkout.workers=4 clone ./linux ./linux-clone
  Time (mean ± σ):     74.479 s ±  2.018 s    [User: 131.830 s, System: 14.459 s]
  Range (min … max):   73.052 s … 75.906 s    2 runs

  Warning: Ignoring non-zero exit code.

Benchmark 8: git -c pack.threads=3 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone
  Time (mean ± σ):     132.084 s ±  2.045 s    [User: 178.106 s, System: 46.505 s]
  Range (min … max):   130.638 s … 133.530 s    2 runs

Benchmark 9: gix -c pack.threads=10 -c checkout.workers=1 clone ./linux ./linux-clone
  Time (mean ± σ):     58.316 s ±  3.864 s    [User: 140.244 s, System: 9.448 s]
  Range (min … max):   55.584 s … 61.048 s    2 runs

  Warning: Ignoring non-zero exit code.

Benchmark 10: git -c pack.threads=10 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone
  Time (mean ± σ):     137.299 s ±  4.889 s    [User: 186.692 s, System: 107.405 s]
  Range (min … max):   133.842 s … 140.756 s    2 runs

Benchmark 11: gix -c pack.threads=10 -c checkout.workers=4 clone ./linux ./linux-clone
  Time (mean ± σ):     54.366 s ±  1.099 s    [User: 140.812 s, System: 13.360 s]
  Range (min … max):   53.588 s … 55.143 s    2 runs

  Warning: Ignoring non-zero exit code.

Benchmark 12: git -c pack.threads=10 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone
  Time (mean ± σ):     132.002 s ±  1.403 s    [User: 187.517 s, System: 107.980 s]
  Range (min … max):   131.010 s … 132.994 s    2 runs

Summary
  'gix -c pack.threads=10 -c checkout.workers=4 clone ./linux ./linux-clone' ran
    1.07 ± 0.07 times faster than 'gix -c pack.threads=10 -c checkout.workers=1 clone ./linux ./linux-clone'
    1.37 ± 0.05 times faster than 'gix -c pack.threads=3 -c checkout.workers=4 clone ./linux ./linux-clone'
    1.45 ± 0.05 times faster than 'gix -c pack.threads=3 -c checkout.workers=1 clone ./linux ./linux-clone'
    2.43 ± 0.06 times faster than 'git -c pack.threads=10 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone'
    2.43 ± 0.06 times faster than 'git -c pack.threads=3 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone'
    2.44 ± 0.05 times faster than 'gix -c pack.threads=1 -c checkout.workers=4 clone ./linux ./linux-clone'
    2.47 ± 0.12 times faster than 'git -c pack.threads=3 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone'
    2.53 ± 0.10 times faster than 'git -c pack.threads=10 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone'
    2.53 ± 0.10 times faster than 'gix -c pack.threads=1 -c checkout.workers=1 clone ./linux ./linux-clone'
    3.46 ± 0.09 times faster than 'git -c pack.threads=1 -c checkout.workers=4 clone file://$PWD/linux ./linux-clone'
    3.48 ± 0.11 times faster than 'git -c pack.threads=1 -c checkout.workers=1 clone file://$PWD/linux ./linux-clone'

gix clone

threads	workers	time [s]	faster than git
1	1	118	1.36x
1	4	113	1.36x
3	1	67	1.72x
3	4	60	1.77x
10	1	49	2.37x
10	4	43	2.58x

threads relates to the amount of threads to use when resolving a pack, the parameter with the greatest influence of overall time consumption. workers defines how many threads can checkout the worktree.

The speedup is calculated compared to the same configuration of git.

git clone

threads	workers	time [s]	percentage of gix
1	1	160	73%
1	4	155	73%
3	1	115	58%
3	4	106	57%
10	1	116	42%
10	4	111	39%

The percentage is calculated compared to the same configuration of gitoxide.

Output of memory consumption tests

gix

git

Note: git launches a sub-process to do the work of receiving a pack which isn't visible here. The sub-process peaks at 2.16GB of real memory, as manually observed in 'Activity Monitor'. This value does not include connectivity checks as they are disabled in this custom build.

❯ git --version
git version 2.38.1.381.gc03801e19c.dirty

❯ /usr/bin/time -lp git clone file://$PWD/linux ./linux-clone
Cloning into './linux-clone'...
warning: templates not found in /usr/local/share/git-core/templates
remote: warning: ignoring extra bitmap file: './objects/pack/pack-d222d0991e3b114f52ef41c3c6711945133cf8db.pack'
remote: Enumerating objects: 8979464, done.
remote: Total 8979464 (delta 0), reused 0 (delta 0), pack-reused 8979464
Receiving objects: 100% (8979464/8979464), 3.58 GiB | 84.98 MiB/s, done.
Resolving deltas: 100% (7492429/7492429), done.
Note: switching to 'b90cb1053190353cc30f0fef0ef1f378ccc063c5'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

Updating files: 100% (78011/78011), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'include/uapi/linux/netfilter/xt_CONNMARK.h'
  'include/uapi/linux/netfilter/xt_connmark.h'
  'include/uapi/linux/netfilter/xt_DSCP.h'
  'include/uapi/linux/netfilter/xt_dscp.h'
  'include/uapi/linux/netfilter/xt_MARK.h'
  'include/uapi/linux/netfilter/xt_mark.h'
  'include/uapi/linux/netfilter/xt_RATEEST.h'
  'include/uapi/linux/netfilter/xt_rateest.h'
  'include/uapi/linux/netfilter/xt_TCPMSS.h'
  'include/uapi/linux/netfilter/xt_tcpmss.h'
  'include/uapi/linux/netfilter_ipv4/ipt_ECN.h'
  'include/uapi/linux/netfilter_ipv4/ipt_ecn.h'
  'include/uapi/linux/netfilter_ipv4/ipt_TTL.h'
  'include/uapi/linux/netfilter_ipv4/ipt_ttl.h'
  'include/uapi/linux/netfilter_ipv6/ip6t_HL.h'
  'include/uapi/linux/netfilter_ipv6/ip6t_hl.h'
  'net/netfilter/xt_DSCP.c'
  'net/netfilter/xt_dscp.c'
  'net/netfilter/xt_HL.c'
  'net/netfilter/xt_hl.c'
  'net/netfilter/xt_RATEEST.c'
  'net/netfilter/xt_rateest.c'
  'net/netfilter/xt_TCPMSS.c'
  'net/netfilter/xt_tcpmss.c'
  'tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus'
  'tools/memory-model/litmus-tests/Z6.0+pooncelock+pooncelock+pombonce.litmus'
real 136.00
user 182.54
sys 72.04
          4446076928  maximum resident set size
                   0  average shared memory size
                   0  average unshared data size
                   0  average unshared stack size
              440495  page reclaims
               62623  page faults
                   0  swaps
                   0  block input operations
                   0  block output operations
                   0  messages sent
                   0  messages received
                 129  signals received
             1134645  voluntary context switches
            10266674  involuntary context switches
         74984112988  instructions retired
         31583334815  cycles elapsed
           200461824  peak memory footprint