From: Jacob Vosmaer <jacob@gitlab.com>
To: git@vger.kernel.org
Cc: Jacob Vosmaer <jacob@gitlab.com>
Subject: [PATCH 1/1] upload-pack.c: make output buffer size configurable
Date: Mon, 13 Dec 2021 14:23:45 +0100 [thread overview]
Message-ID: <20211213132345.26310-2-jacob@gitlab.com> (raw)
In-Reply-To: <20211213132345.26310-1-jacob@gitlab.com>
Add a new compile time constant UPLOAD_PACK_BUFFER_SIZE that makes the
size of the static buffer in output_state configurable.
The current size of the buffer is 8192+1. The '+1' is a technical
detail orthogonal to this change. On GitLab.com we use GitLab's
pack-objects cache which does writes of 65515 bytes. Because of the
default 8KB buffer size, propagating these cache writes requires 8
pipe reads and 8 pipe writes from git-upload-pack, and 8 pipe reads
from Gitaly (our Git RPC service). If we increase the size of the
buffer to the maximum Git packet size, we need only 1 pipe read and 1
pipe write in git-upload-pack, and 1 pipe read in Gitaly to transfer
the same amount of data. In benchmarks with a pure fetch and 100%
cache hit rate workload we are seeing CPU utilization reductions of
over 30%.
Signed-off-by: Jacob Vosmaer <jacob@gitlab.com>
---
upload-pack.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/upload-pack.c b/upload-pack.c
index c78d55bc67..b799fbe628 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -42,6 +42,10 @@
#define ALL_FLAGS (THEY_HAVE | OUR_REF | WANTED | COMMON_KNOWN | SHALLOW | \
NOT_SHALLOW | CLIENT_SHALLOW | HIDDEN_REF)
+#ifndef UPLOAD_PACK_BUFFER_SIZE
+#define UPLOAD_PACK_BUFFER_SIZE 8192
+#endif
+
/* Enum for allowed unadvertised object request (UOR) */
enum allow_uor {
/* Allow specifying sha1 if it is a ref tip. */
@@ -194,7 +198,7 @@ static int write_one_shallow(const struct commit_graft *graft, void *cb_data)
}
struct output_state {
- char buffer[8193];
+ char buffer[UPLOAD_PACK_BUFFER_SIZE+1];
int used;
unsigned packfile_uris_started : 1;
unsigned packfile_started : 1;
--
2.33.0
next prev parent reply other threads:[~2021-12-13 13:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 13:23 [PATCH 0/1] Make upload-pack pack write size configurable Jacob Vosmaer
2021-12-13 13:23 ` Jacob Vosmaer [this message]
2021-12-14 12:08 ` [PATCH 1/1] upload-pack.c: make output buffer " Ævar Arnfjörð Bjarmason
2021-12-14 15:08 ` Jeff King
2021-12-14 19:46 ` [PATCH v2 0/1] upload-pack.c: increase output buffer size Jacob Vosmaer
2021-12-14 19:46 ` [PATCH v2 1/1] " Jacob Vosmaer
2021-12-14 20:41 ` Ævar Arnfjörð Bjarmason
2021-12-15 16:30 ` Jeff King
2021-12-15 19:50 ` Junio C Hamano
2021-12-15 19:59 ` rsbecker
2021-12-15 20:24 ` Jacob Vosmaer
2021-12-15 20:38 ` rsbecker
2021-12-15 20:45 ` Jacob Vosmaer
2021-12-15 21:34 ` rsbecker
2021-12-14 15:37 ` [PATCH 1/1] upload-pack.c: make output buffer size configurable Jeff King
2021-12-14 20:04 ` Jacob Vosmaer
2021-12-14 15:12 ` [PATCH 0/1] Make upload-pack pack write " Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211213132345.26310-2-jacob@gitlab.com \
--to=jacob@gitlab.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.