[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090420125653.GA28858@amit-x200.pnq.redhat.com>
Date: Mon, 20 Apr 2009 18:26:53 +0530
From: Amit Shah <amit.shah@...hat.com>
To: Mike Galbraith <efault@....de>
Cc: Jan Kara <jack@...e.cz>, Theodore Tso <tytso@....edu>,
Chris Mason <chris.mason@...cle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] Add ext3 data=guarded mode
On (Mon) Apr 20 2009 [14:15:14], Mike Galbraith wrote:
> On Mon, 2009-04-20 at 11:26 +0200, Jan Kara wrote:
> > On Mon 20-04-09 11:07:17, Mike Galbraith wrote:
> > > All journal modes seem subject to bad throughput under heavy pressure,
> > > though data=ordered seems much less likely to suffer for some reason.
> > > Major difference _seems_ to be that write()+largefile induces very much
> > > swap activity.
>
> > My rough guess is that this depends on the VM writeout behavior. In
> > ordered mode, we forcibly writeout all the dirty data on a transaction
> > commit which happens every 5 seconds so they don't accumulate that much.
>
> Aha.
>
> > In other journaling modes we don't do that and decisions about writeout
> > (probably how much pdflush manages to write in background vs. how much
> > VM throttles the process to do the writeback itself) cause variances in
> > the run time. But this is just a guess. You could gather blktraces of
> > slow and fast runs and then look if the amount of IO done by different
> > processes significantly differs. If Chris has merged by improvements to
> > Seekwatcher, then you could nicely visualize this (hmm, that doesn't seem
> > to be the case so I'm attaching the diff and a helper script - see comments
> > in the beginning of the script and command helps for usage).
>
> Not necessary methinks. Actually _reading_ the proggy instead of just
> glancing at it...
>
> @@ -178,7 +178,7 @@ int do_write_chunks(char *target, int *f
> unsigned long long remain = len;
> char *zeros;
>
> - zeros = calloc(1, len);
> + zeros = calloc(1, data);
>
> I assume that was a booboo.
Ouch! thanks for spotting that!
I'll re-run the tests later tonight..
Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists