Re: [PATCH 2/2] upload-pack: reduce lock contention when writing packfile data

> On Fri, Feb 27, 2026 at 12:23:01PM +0100, Patrick Steinhardt wrote:
> 
> > Extend our use of the buffering infrastructure so that we soak up bytes
> > until the buffer is filled up at least 2/3rds of its capacity. The
> > change is relatively simple to implement as we already know to flush the
> > buffer in `create_pack_file()` after git-pack-objects(1) has finished.
> 
> We are relaying write() calls from pack-objects here, which is writing
> to us in 8kb chunks (due to csum-file.c buffering). So most of our
> writes will be 8k.
> 
> Rather than buffering in upload-pack, would it not be simpler to just
> increase the write size from pack-objects? Then we do not have to worry
> about disrupting upload-pack's keepalive timeouts. And as a bonus, if
> you are worried about the system-wide number of calls, you will likewise
> be reducing the number of read() and write() calls over the pipe between
> pack-objects and upload-pack.

> > Now git-upload-pack(1) already has the infrastructure in place to buffer
> > some of the data it reads from git-pack-objects(1) before actually
> > sending it out. We only use this infrastructure in very limited ways
> > though, so we generally end up matching one read(3p) call with one
> > write(3p) call. Even worse, when the sideband is enabled we end up
> > matching one read with _two_ writes: one for the pkt-line length, and
> > one for the packfile data.
> 
> Using writev() would be an easy-ish fix here, modulo portability
> concerns (though of course it is easy to implement a fallback writev()
> in terms of write()). Doing this:

> Out of curiosity, how did you end up measuring? I first tried with
> strace (without "-f") on the upload-pack process, but strace slowed it
> enough that it ended up collecting multiple of pack-object's 8k write()
> calls in a single read() call. ;) The "perf stat" above seemed to work
> OK, though of course it's counting child processes, too.