From: Larry McVoy <lm@bitmover.com>
To: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2003@gmx.net>
Cc: Neil Brown <neilb@cse.unsw.edu.au>, Larry McVoy <lm@bitmover.com>,
linux-kernel@vger.kernel.org, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: BK->CVS, kernel.bkbits.net
Date: Wed, 23 Apr 2003 19:45:49 -0700 [thread overview]
Message-ID: <20030424024549.GA10840@work.bitmover.com> (raw)
In-Reply-To: <3EA6B61B.7030303@gmx.net>
On Wed, Apr 23, 2003 at 05:49:47PM +0200, Carl-Daniel Hailfinger wrote:
> > % time bk pull
> > ....
> > 444.95user 42.29system 49:09.46elapsed 16%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (326737major+196385minor)pagefaults 0swaps
> >
> >
> > % time cvs update
> > .....
> > 2.78user 1.94system 4:12.36elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (333major+7240minor)pagefaults 0swaps
Fast or safe, pick one. CVS has no integrity check and you will never know
if you have bad data or not. And the BK checks find el cheapo memory dimms
and all sorts of other problems all the time. It even found a cache aliasing
bug in SPARC/Linux...
The BK integrity check will tell you right away if any of your data is bad.
*Everyone* hates the check until it saves their butt and then they decide
it's not such a bad idea. It's a lot like a seatbelt - you don't like it
until something goes wrong.
BK != CVS. You want fast and loose, by all means, use CVS, that's not our
intended market and we don't care about fast where fast means bad data.
> > That is an order of magnitude difference in wall-clock time! This is
> > on my humble notebook with "only" 128Meg of RAM. The delay is mostly
> > in the consistency checking. Sure there is a way to turn that off.
>
> Just add this line to your /etc/BitKeeper/etc/config:
> []partial_check:yes!
>
> and you should notice a big speedup.
>
> P.S. If anyone knows other speedup tricks for a kernel tree in bk,
> please tell me.
Mount the file system with noatime.
Buy enough memory to fit the kernel in memory and on a 1Ghz processor that
pull will take about 20 seconds. Even laptop memory is pretty cheap these
days. Pricewatch says $80 for .5GB for laptops, that's cheap.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next prev parent reply other threads:[~2003-04-24 2:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-17 16:27 BK->CVS, kernel.bkbits.net Larry McVoy
2003-04-17 20:52 ` H. Peter Anvin
2003-04-20 0:30 ` Larry McVoy
2003-04-20 13:16 ` Roman Zippel
2003-04-20 15:23 ` Larry McVoy
2003-04-20 15:42 ` Roman Zippel
2003-04-21 4:46 ` Neil Brown
2003-04-21 6:58 ` Jeff Garzik
2003-04-23 15:49 ` Carl-Daniel Hailfinger
2003-04-24 2:45 ` Larry McVoy [this message]
2003-04-24 7:21 ` Christoph Hellwig
2003-04-24 9:19 ` Carl-Daniel Hailfinger
2003-04-21 15:58 ` Jamie Lokier
2003-04-20 1:34 ` Ben Collins
2003-04-20 1:49 ` Larry McVoy
2003-04-21 18:58 ` H. Peter Anvin
2003-04-21 21:41 ` Ben Collins
2003-04-20 7:32 ` Shachar Shemesh
2003-04-20 9:58 ` Geert Uytterhoeven
2003-04-20 13:47 ` Shachar Shemesh
2003-04-20 13:01 ` Ben Collins
2003-04-20 13:37 ` Shachar Shemesh
2003-04-20 13:42 ` viro
2003-04-20 13:47 ` Ben Collins
2003-04-20 14:13 ` Shachar Shemesh
2003-04-20 14:42 ` Shachar Shemesh
2003-04-20 14:47 ` Wichert Akkerman
2003-04-20 14:58 ` Shachar Shemesh
2003-04-20 15:45 ` viro
2003-04-22 11:09 ` Gerd Knorr
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=20030424024549.GA10840@work.bitmover.com \
--to=lm@bitmover.com \
--cc=c-d.hailfinger.kernel.2003@gmx.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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).