From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: [PATCH] Teach 'git checkout' to preload the index contents
Date: Sat, 9 May 2009 15:41:17 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0905091517000.3586@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.01.0905091501460.3586@localhost.localdomain>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 9 May 2009 15:11:17 -0700
This makes git checkout know to use the threaded index preloading if it
is enabled in the config file. You need to have
[core]
preloadindex = true
in your config file to see it, and for that feature to make sense your
filesystem needs to be able to do concurrent 'lstat()' lookups, but when
that is the case (especially NFS over a high-latency network), this can
be a noticeable performance win.
But with a low-latency network and at least older Linux NFS clients, this
will clearly potentially cause a lot of lock contention. It may still
speed up the uncached case, but the threading and locking overhead will
result in the cached case likely slowing down.
That was almost certainly fixed by Linux commit fc0f684c2 ("NFS: Remove
BKL from NFS lookup code"), but that one got merged into 2.6.27-rc1, so
older kernel versions than 2.6.27 will not scale very well.
But regardless, it's the right thing to do. If your filesystem doesn't
scale, don't enable index preloading.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
On local filesystems, I've actually seen signs of tiny speedups (iow,
0.15s -> 0.14s in the cached case on a much-too-fast-for-this-to-matter
Nehalem machine) due to SMP scaling.
But it's probably more likely to slow things down, unless you have a disk
that does TCQ and really gets improved by having multiple outstanding
requests.
Again, this is not so much a "git checkout" issue, as a generic
"core.preloadindex" issue.
builtin-checkout.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 15f0c32..3100ccd 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -216,7 +216,7 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec,
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
newfd = hold_locked_index(lock_file, 1);
- if (read_cache() < 0)
+ if (read_cache_preload(pathspec) < 0)
return error("corrupt index file");
if (source_tree)
@@ -367,7 +367,7 @@ static int merge_working_tree(struct checkout_opts *opts,
int newfd = hold_locked_index(lock_file, 1);
int reprime_cache_tree = 0;
- if (read_cache() < 0)
+ if (read_cache_preload(NULL) < 0)
return error("corrupt index file");
cache_tree_free(&active_cache_tree);
--
1.6.3.1.g3f31
next prev parent reply other threads:[~2009-05-09 22:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-09 22:09 [PATCH] Avoid unnecessary 'lstat()' calls in 'get_stat_data()' Linus Torvalds
2009-05-09 22:41 ` Linus Torvalds [this message]
2009-05-10 4:20 ` Junio C Hamano
2009-05-10 16:50 ` Linus Torvalds
2009-05-10 17:45 ` Johannes Schindelin
2009-05-10 18:40 ` Junio C Hamano
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=alpine.LFD.2.01.0905091517000.3586@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).