From: Jeff King <peff@peff.net>
To: Thomas Rast <trast@student.ethz.ch>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Junio C Hamano <gitster@pobox.com>,
"Lars R. Damerow" <lars@pixar.com>,
git@vger.kernel.org
Subject: Re: [PATCH 3/3] Add support for GIT_ONE_FILESYSTEM
Date: Tue, 30 Mar 2010 19:04:08 -0400 [thread overview]
Message-ID: <20100330230408.GD608@coredump.intra.peff.net> (raw)
In-Reply-To: <201003310059.33937.trast@student.ethz.ch>
On Wed, Mar 31, 2010 at 12:59:33AM +0200, Thomas Rast wrote:
> Linus Torvalds wrote:
> >
> > I suspect that it is _very_ unusual to have a source repo that crosses
> > multiple filesystems, and the original reason for this patch-series seems
> > to me to be likely to be more common than that multi-fs case. So having
> > the logic go the other way would seem to match the common case, no?
>
> Not sure if I'm the only one, but I noticed at some point that
> mounting the t/ directory of git.git on tmpfs gives a huge speed boost
> to the test suite...
I noticed it, too, but my solution was a little different:
$ git show f423ef5f
tests: allow user to specify trash directory location
The tests generate a large amount of I/O activity creating
and destroying repositories and files. We can improve the
time it takes to run the test suite by creating trash
directories on filesystems with better performance
characteristic, even though we may not want the rest of the
git repository on those filesystems (e.g., because they are
not network connected, or because they are temporary
ramdisks).
For example, on a dual processor system:
$ cd t && time make -j32
real 1m51.562s
user 0m59.260s
sys 1m20.933s
# /dev/shm is tmpfs
$ cd t && time make -j32 GIT_TEST_OPTS="--root=/dev/shm"
real 1m1.484s
user 0m53.555s
sys 1m5.264s
-Peff
next prev parent reply other threads:[~2010-03-30 23:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 19:55 [PATCH v3 0/3] Add support for GIT_ONE_FILESYSTEM Lars R. Damerow
2010-03-17 19:55 ` [PATCH 1/3] config.c: remove static keyword from git_env_bool() Lars R. Damerow
2010-03-17 19:55 ` [PATCH 2/3] truncate cwd string before printing error message Lars R. Damerow
2010-03-17 19:55 ` [PATCH 3/3] Add support for GIT_ONE_FILESYSTEM Lars R. Damerow
2010-03-28 9:22 ` Jeff King
2010-03-28 12:05 ` Jeff King
2010-03-28 16:44 ` Junio C Hamano
2010-03-28 17:32 ` Lars Damerow
2010-03-30 15:58 ` Jeff King
2010-03-30 22:43 ` Linus Torvalds
2010-03-30 22:59 ` Thomas Rast
2010-03-30 23:04 ` Jeff King [this message]
2010-03-30 23:02 ` Jeff King
2010-03-30 23:10 ` Junio C Hamano
2010-03-30 23:12 ` Linus Torvalds
2010-03-31 0:54 ` Erik Faye-Lund
2010-04-04 18:00 ` [PATCH] GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries Junio C Hamano
2010-04-04 22:30 ` [PATCH] Rename ONE_FILESYSTEM to DISCOVERY_ACROSS_FILESYSTEM Junio C Hamano
2010-04-04 22:37 ` Matthieu Moy
2010-04-04 22:39 ` [PATCH] GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries 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=20100330230408.GD608@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=lars@pixar.com \
--cc=torvalds@linux-foundation.org \
--cc=trast@student.ethz.ch \
/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).