From: Karthik Nayak <karthik.188@gmail.com>
To: git@vger.kernel.org
Cc: Karthik Nayak <karthik.188@gmail.com>, Jeff King <peff@peff.net>
Subject: [PATCH 0/3] reftable/stack: avoid reloading the stack when locked
Date: Wed, 19 Aug 2026 15:19:36 +0200 [thread overview]
Message-ID: <20260819-740-optimize-reloading-the-reftable-stack-v1-0-6bf5305d4e43@gmail.com> (raw)
This patch series is based on the report by Jeff [1], where he noticed
that when creating a lot of refs within a single reference transaction,
the majority of the time was spent on fstat().
The issue stems from the fact that within the reftable library we do not
track Git reference transactions, as such any calls within the library
would potentially reload the stack to ensure that there are no
concurrent updates made to the stack. While this makes sense outside of
a reference transaction, within one, the stack is locked, so reloading
the stack is a no-op. The only time we want to reload the stack is
immediately after locking the list file, which is to catch any
concurrent updates made to the stack.
The first patch in this small series, cleans up the flow of reloading
the stack by providing a flag explicitly. The patch argues that since
all flows reload the stack, the flag can be safely removed. This
simplifies the flow of when to reload the stack.
The next two commits move the lock variable to the reftable_stack
structure and then use this information to decide if reloading of the
stack is necessary.
During benchmarking, I first tried to benchmark adding new references
against HEAD. This kicks in the DWIM ref resolution, and we iterate over
siz difference candidate ref names before settling on a match. Each such
lookup reloads the stack. This happens before the reference transaction
is created. I quickly realized that this would dominate the benchmarks,
so the benchmarks in the third patch are against a static commit OID.
The benchmarks show a consistent 1-2% improvement in clock time for
'git-update-ref(1)', but such low values could also be chalked to being
within an error rate. However, the syscall counts show that now the
calls to `newfstatat()` stay constant at around 55 calls regardless of
the number of refs to be created. Before this would grow linearly with
the number of refs.
[1]: https://lore.kernel.org/git/20260629203527.GA1895313@coredump.intra.peff.net/
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
---
Karthik Nayak (3):
reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD`
reftable/stack: move list lock to `struct reftable_stack`
reftable/stack: avoid reloading the stack when already locked
refs/reftable-backend.c | 18 ++++-------
reftable/reftable-stack.h | 17 ++--------
reftable/stack.c | 69 +++++++++++++++++------------------------
reftable/stack.h | 7 ++++-
t/unit-tests/u-reftable-stack.c | 69 ++++++++++++++++++-----------------------
5 files changed, 75 insertions(+), 105 deletions(-)
---
base-commit: 18e66859d87fb4b76599f73460b54f0848c76b16
change-id: 20260814-740-optimize-reloading-the-reftable-stack-f5f3adf0a0c0
Thanks
- Karthik
next reply other threads:[~2026-08-19 13:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 13:19 Karthik Nayak [this message]
2026-08-19 13:19 ` [PATCH 1/3] reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD` Karthik Nayak
2026-08-19 16:28 ` Justin Tobler
2026-08-19 13:19 ` [PATCH 2/3] reftable/stack: move list lock to `struct reftable_stack` Karthik Nayak
2026-08-19 16:39 ` Justin Tobler
2026-08-19 17:17 ` Junio C Hamano
2026-08-19 13:19 ` [PATCH 3/3] reftable/stack: avoid reloading the stack when already locked Karthik Nayak
2026-08-19 16:49 ` Justin Tobler
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=20260819-740-optimize-reloading-the-reftable-stack-v1-0-6bf5305d4e43@gmail.com \
--to=karthik.188@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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.