Re: Mercurial 0.3 vs git benchmarks
From: Chris Mason
Date: Tue Apr 26 2005 - 12:55:59 EST
On Tuesday 26 April 2005 12:42, Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Chris Mason wrote:
> > This agrees with my tests here, the time to apply patches is somewhat
> > disk bound, even for the small 100 or 200 patch series. The io should be
> > coming from data=ordered, since the commits are still every 5 seconds or
> > so.
> Yes, ext3 really does suck in many ways.
> One of my (least) favourite suckage is a process that does "fsync" on a
> single file (mail readers etc), which apparently causes ext3 to sync all
> dirty data, because it can only sync the whole log. So if you have stuff
> that writes out things that aren't critical, it negatively affects
> something totally independent that _does_ care.
> I remember some early stuff showing that reiserfs was _much_ better for
> BK. I'd be willing to bet that's probably true for git too.
reiserfs shares the same basic data=ordered idea as ext3, so the fsync will do
the same on reiser as it does on ext3. I do have code in there to try and
keep the data=ordered writeback a little less bursty than it is in ext3 so
you might not notice the fsync as much.
I haven't compared reiser vs ext3 for git. reiser tails should help
performance because once you read the object inode you've also got the data.
But, I would expect the biggest help to come from mounting reiserfs -o
alloc=skip_busy. This basically allocates all new files one right after the
other on disk regardless of which subdir they are in. The effect is to time
order most of your files.
As an example, here's the time to apply 300 patches on ext3. This was with my
packed patches applied, but vanilla git should show similar percentage
With a long enough test, data=ordered should fall into the noise, but 10-40
second runs really show it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/