From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Larry McVoy <lm@bitmover.com>
Cc: linux-kernel@vger.kernel.org, dev@bitmover.com
Subject: Re: boring BK stats
Date: Sun, 22 Sep 2002 22:01:39 -0400 [thread overview]
Message-ID: <3D8E7603.5060106@mandrakesoft.com> (raw)
In-Reply-To: 200209222356.g8MNu4V10172@work.bitmover.com
Larry McVoy wrote:
> I should be working on getting the bk-3.0 release done but I'm sick of
> fixing BK-on-windows bugs...
>
> Linus' kernel tree has 13333 revision controlled files in it. Without
> repository compression, it eats up 280M in an ext2 fs. With repository
> compression, that drops to 129M. After checking out all the files, the
> size of the revision history and the checked out files is 317MB when
> the revision history is compressed. That means the tree without the
> history is 188MB, we get the revision history in less space than the
> checked out tree. That's pretty cool, by the way, I know of no other
> SCM system which can say that.
>
> Checking out the tree takes 16 seconds. Doing an integrity check takes 10
> seconds if the repository is uncompressed, 15 seconds if it is compressed.
> That's on 1.3Ghz Athlon w/ PC133 memory running at the slower CAS rate,
> but lots of it, around 900MB.
If you can't fit a whole tree including metadata into RAM, though, BK
crawls... Going from "bk citool" at the command line to actually
seeing the citool window approaches five minutes of runtime, on this
200MB laptop... [my dual athlon with 512MB RAM corroborates your
numbers, though] "bk -r co -Sq" takes a similar amount of time...
I also find that BK brings out the worst in the 2.4 kernel
elevator/VM... mouse clicks in Mozilla take upwards of 10 seconds to
respond, when "bk -r co -Sq" is running on this laptop [any other
read-from-disk process behaves similarly]. And running any two BK jobs
at the same time is a huge mistake. Two "bk -r co -Sq" runs easily take
four or more times longer than a single run. Ditto for consistency
checks, or any other disk-intensive activity BK indulges in.
Next time I get super-annoyed at BK on this laptop, I'm gonna look into
beating the disk scheduler into submission... some starvation is
clearly occurring.
</rant>
Jeff
prev parent reply other threads:[~2002-09-23 1:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-22 23:56 boring BK stats Larry McVoy
2002-09-23 2:01 ` Jeff Garzik [this message]
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=3D8E7603.5060106@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=dev@bitmover.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.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).