git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2 0/5] Allocate cache entries from memory pool

From
Jameson Miller <jamill@microsoft.com>
Date
Apr 30, 2018, 15:31 UTC
Message-ID
<20180430153122.243976-1-jamill@microsoft.com>
In-Reply-To
<20180417163400.3875-1-jamill@microsoft.com>
Changes from V1:
 - Based patch series off of commit in master
 - Minor updates based on initial code review feedback
Summary:

This patch series improves the performance of loading indexes by reducing the number of malloc() calls. Loading the index from disk is partly dominated by the time in malloc(), which is called for each index entry. This patch series reduces the number of times malloc() is called as part of loading the index, and instead allocates a block of memory upfront that is large enough to hold all of the cache entries, and chunks this memory itself. This change builds on [1].

Git previously allocated block of memory for the index cache entries until [2].

This 5 part patch series is broken up as follows:
  1/5, 2/5 - Move cache entry lifecycle methods behind an API
  3/5 - Fill out memory pool API to include lifecycle and other
      	methods used in later patches
  4/5 - Allocate cache entry structs from memory pool
  5/5 - Add extra optional validation
Performance Benchmarks:

To evaluate the performance of this approach, the p0002-read-cache.sh test was run with several combinations of allocators (glibc default, tcmalloc, jemalloc), with and without block allocation, and across several different index sized (100K, 1M, 2M entries). The details on how these repositories were constructed can be found in [3].The p0002-read-cache.sh was run with the iteration count set to 1 and $GIT_PERF_REPEAT_COUNT=10.

The tests were run with iteration count set to 1 because this best approximates the real behavior. The read_cache/discard_cache test will load / free the index N times, and the performance of this logic is different between N = 1 and N > 1. As the production code does not read / discard the index in a loop, a better approximation is when N = 1.

100K
Test                                       baseline           block_allocation
 ------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1 times   0.03(0.01+0.01)    0.02(0.01+0.01) -33.3%
1M:
Test                                       baseline           block_allocation
 ------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1 times   0.23(0.12+0.11)    0.17(0.07+0.09) -26.1%
2M:
Test                                       baseline           block_allocation
 ------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1 times   0.45(0.26+0.19)    0.39(0.17+0.20) -13.3%

With 100K entries, it only takes 0.3 seconds to read the entries even without using block allocation, so there is only a small change in the wall clock time. We can see a larger wall clack improvement with 1M and 2M entries.

For completeness, here is the p0002-read-cache tests for git.git and linux.git:

git.git:
Test                                          baseline          block_allocation
 ---------------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1000 times   0.30(0.26+0.03)   0.17(0.13+0.03) -43.3%
linux.git:
Test                                          baseline          block_allocation
 ---------------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1000 times   7.05(6.01+0.84)   4.61(3.74+0.66) -34.6%

We also investigated the performance of just using different allocators. We can see that there is not a consistent performance gain.

100K
Test                                       baseline          tcmalloc                  jemalloc
 ------------------------------------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1 times   0.03(0.01+0.01)   0.03(0.01+0.01) +0.0%     0.03(0.02+0.01) +0.0% 
1M:
Test                                       baseline          tcmalloc                  jemalloc
 ------------------------------------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1 times   0.23(0.12+0.11)   0.21(0.10+0.10) -8.7%     0.27(0.16+0.10) +17.4%
2M:
Test                                       baseline          tcmalloc                  jemalloc
 ------------------------------------------------------------------------------------------------------------------
0002.1: read_cache/discard_cache 1 times   0.45(0.26+0.19)   0.46(0.25+0.21) +2.2%     0.57(0.36+0.21) +26.7%
[1] https://public-inbox.org/git/20180321164152.204869-1-jamill@microsoft.com/
[2] debed2a629 (read-cache.c: allocate index entries individually - 2011-10-24)
[3] Constructing test repositories:
The test repositories were constructed with t/perf/repos/many_files.sh with the following parameters:

100K: many-files.sh 4 10 9 1M: many-files.sh 5 10 9 2M: many-files.sh 6 8 7

Base Ref: master
Web-Diff: git@github.com:jamill/git.git/commit/2152d28016
Checkout: git fetch git@github.com:jamill/git.git users/jamill/block_allocation-v2 && git checkout 2152d28016
Jameson Miller (5):
  read-cache: teach refresh_cache_entry() to take istate
  block alloc: add lifecycle APIs for cache_entry structs
  mem-pool: fill out functionality
  block alloc: allocate cache entries from mem_pool
  block alloc: add validations around cache_entry lifecyle
 apply.c                |  26 +++---
 blame.c                |   5 +-
 builtin/checkout.c     |   8 +-
 builtin/difftool.c     |   8 +-
 builtin/reset.c        |   6 +-
 builtin/update-index.c |  26 +++---
 cache.h                |  40 ++++++++-
 git.c                  |   3 +
 mem-pool.c             | 136 ++++++++++++++++++++++++++++-
 mem-pool.h             |  34 ++++++++
 merge-recursive.c      |   4 +-
 read-cache.c           | 232 +++++++++++++++++++++++++++++++++++++++----------
 resolve-undo.c         |   6 +-
 split-index.c          |  31 +++++--
 tree.c                 |   4 +-
 unpack-trees.c         |  27 +++---
 16 files changed, 479 insertions(+), 117 deletions(-)
base-commit: 1f1cddd558b54bb0ce19c8ace353fd07b758510d
-- 
2.14.3
Previous: Jameson MillerNext: Jameson Miller
Message 23 of 100 in “Allocate cache entries from memory pool”
  1. 0/5 Allocate cache entries from memory poolJameson Miller, Apr 17, 2018
  2. 0/5 Allocate cache entries from memory poolJameson Miller, Apr 17, 2018
  3. 2/5 Add an API creating / discarding cache_entry structsJameson Miller, Apr 17, 2018
  4. Ben PeartApr 17, 2018
  5. 1/5 read-cache: teach refresh_cache_entry to take istateJameson Miller, Apr 17, 2018
  6. Ben PeartApr 17, 2018
  7. 3/5 mem-pool: fill out functionalityJameson Miller, Apr 17, 2018
  8. Jonathan TanApr 20, 2018
  9. Jameson MillerApr 23, 2018
  10. Jonathan TanApr 23, 2018
  11. Jameson MillerApr 23, 2018
  12. 5/5 Add optional memory validations around cache_entry lifecyleJameson Miller, Apr 17, 2018
  13. 4/5 Allocate cache entries from memory poolsJameson Miller, Apr 17, 2018
  14. Ben PeartApr 17, 2018
  15. Jameson MillerApr 23, 2018
  16. Junio C HamanoApr 18, 2018
  17. Stefan BellerApr 20, 2018
  18. Jameson MillerApr 23, 2018
  19. Stefan BellerApr 23, 2018
  20. Jameson MillerApr 23, 2018
  21. Jonathan TanApr 20, 2018
  22. Jameson MillerApr 23, 2018
  23. 0/5 Allocate cache entries from memory poolJameson Miller, Apr 30, 2018
  24. 1/5 read-cache: teach refresh_cache_entry() to take istateJameson Miller, Apr 30, 2018
  25. 3/5 mem-pool: fill out functionalityJameson Miller, Apr 30, 2018
  26. Stefan BellerApr 30, 2018
  27. Jameson MillerMay 1, 2018
  28. Duy NguyenMay 3, 2018
  29. 5/5 block alloc: add validations around cache_entry lifecyleJameson Miller, Apr 30, 2018
  30. Duy NguyenMay 3, 2018
  31. 2/5 block alloc: add lifecycle APIs for cache_entry structsJameson Miller, Apr 30, 2018
  32. 4/5 block alloc: allocate cache entries from mem_poolJameson Miller, Apr 30, 2018
  33. Duy NguyenMay 3, 2018
  34. Stefan BellerMay 3, 2018
  35. Duy NguyenMay 3, 2018
  36. Stefan BellerMay 3, 2018
  37. Jameson MillerMay 3, 2018
  38. alloc.c: replace alloc by mempoolStefan Beller, May 3, 2018
  39. Duy NguyenMay 4, 2018
  40. Junio C HamanoMay 8, 2018
  41. Stefan BellerMay 8, 2018
  42. Junio C HamanoMay 8, 2018
  43. 0/7 allocate cache entries from memory poolJameson Miller, May 23, 2018
  44. 1/7 read-cache: teach refresh_cache_entry() to take istateJameson Miller, May 23, 2018
  45. Stefan BellerMay 25, 2018
  46. 3/7 mem-pool: only search head block for available spaceJameson Miller, May 23, 2018
  47. 2/7 block alloc: add lifecycle APIs for cache_entry structsJameson Miller, May 23, 2018
  48. Junio C HamanoMay 24, 2018
  49. Jameson MillerMay 24, 2018
  50. 4/7 mem-pool: add lifecycle management functionsJameson Miller, May 23, 2018
  51. 5/7 mem-pool: fill out functionalityJameson Miller, May 23, 2018
  52. Stefan BellerJun 1, 2018
  53. 6/7 block alloc: allocate cache entries from mem_poolJameson Miller, May 23, 2018
  54. 7/7 block alloc: add validations around cache_entry lifecyleJameson Miller, May 23, 2018
  55. Junio C HamanoMay 24, 2018
  56. Jameson MillerMay 24, 2018
  57. Stefan BellerMay 25, 2018
  58. Jameson MillerJun 20, 2018
  59. Stefan BellerMay 25, 2018
  60. 0/8 Allocate cache entries from mem_poolJameson Miller, Jun 20, 2018
  61. 1/8 read-cache: teach refresh_cache_entry() to take istateJameson Miller, Jun 20, 2018
  62. 3/8 mem-pool: only search head block for available spaceJameson Miller, Jun 20, 2018
  63. Stefan BellerJun 21, 2018
  64. Jameson MillerJun 28, 2018
  65. 5/8 mem-pool: add lifecycle management functionsJameson Miller, Jun 20, 2018
  66. 8/8 block alloc: add validations around cache_entry lifecyleJameson Miller, Jun 20, 2018
  67. 7/8 block alloc: allocate cache entries from mem_poolJameson Miller, Jun 20, 2018
  68. 4/8 mem-pool: tweak math on mp_block allocation sizeJameson Miller, Jun 20, 2018
  69. 2/8 block alloc: add lifecycle APIs for cache_entry structsJameson Miller, Jun 20, 2018
  70. Stefan BellerJun 21, 2018
  71. Jameson MillerJun 28, 2018
  72. 6/8 mem-pool: fill out functionalityJameson Miller, Jun 20, 2018
  73. 0/8 Allocate cache entries from mem_poolJameson Miller, Jun 28, 2018
  74. 2/8 read-cache: make_cache_entry should take object_id structJameson Miller, Jun 28, 2018
  75. Junio C HamanoJun 28, 2018
  76. SZEDER GáborJun 28, 2018
  77. 3/8 block alloc: add lifecycle APIs for cache_entry structsJameson Miller, Jun 28, 2018
  78. Junio C HamanoJun 28, 2018
  79. SZEDER GáborJun 28, 2018
  80. 5/8 mem-pool: add life cycle management functionsJameson Miller, Jun 28, 2018
  81. Junio C HamanoJun 28, 2018
  82. 4/8 mem-pool: only search head block for available spaceJameson Miller, Jun 28, 2018
  83. 6/8 mem-pool: fill out functionalityJameson Miller, Jun 28, 2018
  84. Junio C HamanoJun 28, 2018
  85. Jameson MillerJul 2, 2018
  86. 8/8 block alloc: add validations around cache_entry lifecyleJameson Miller, Jun 28, 2018
  87. 1/8 read-cache: teach refresh_cache_entry() to take istateJameson Miller, Jun 28, 2018
  88. 7/8 block alloc: allocate cache entries from mem-poolJameson Miller, Jun 28, 2018
  89. 0/8 Allocate cache entries from mem_poolJameson Miller, Jul 2, 2018
  90. 2/8 read-cache: teach make_cache_entry to take object_idJameson Miller, Jul 2, 2018
  91. Stefan BellerJul 2, 2018
  92. Jameson MillerJul 5, 2018
  93. 3/8 block alloc: add lifecycle APIs for cache_entry structsJameson Miller, Jul 2, 2018
  94. Duy NguyenJul 22, 2018
  95. 4/8 mem-pool: only search head block for available spaceJameson Miller, Jul 2, 2018
  96. 5/8 mem-pool: add life cycle management functionsJameson Miller, Jul 2, 2018
  97. 7/8 block alloc: allocate cache entries from mem_poolJameson Miller, Jul 2, 2018
  98. 8/8 block alloc: add validations around cache_entry lifecyleJameson Miller, Jul 2, 2018
  99. 6/8 mem-pool: fill out functionalityJameson Miller, Jul 2, 2018
  100. 1/8 read-cache: teach refresh_cache_entry to take istateJameson Miller, Jul 2, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.