linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Jan Kara <jack@suse.cz>, Theodore Tso <tytso@mit.edu>,
	Chris Mason <chris.mason@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] Add ext3 data=guarded mode
Date: Mon, 20 Apr 2009 18:26:53 +0530	[thread overview]
Message-ID: <20090420125653.GA28858@amit-x200.pnq.redhat.com> (raw)
In-Reply-To: <1240229714.6469.33.camel@marge.simson.net>

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

  reply	other threads:[~2009-04-20 12:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-15 17:22 [PATCH RFC] ext3 data=guarded v3 Chris Mason
2009-04-15 17:22 ` [PATCH 1/3] Export filemap_write_and_wait_range Chris Mason
2009-04-15 17:22   ` [PATCH 2/3] Add block_write_full_page_endio for passing endio handler Chris Mason
2009-04-15 17:22   ` [PATCH 3/3] Add ext3 data=guarded mode Chris Mason
2009-04-16 19:42     ` [PATCH] " Chris Mason
2009-04-17 11:04       ` Mike Galbraith
2009-04-17 18:09       ` Amit Shah
2009-04-17 20:13         ` Theodore Tso
2009-04-18  6:03           ` Amit Shah
     [not found]           ` <20090418060312.GA10943@amit-x200.pnq.redhat.com>
2009-04-18  7:28             ` Mike Galbraith
2009-04-19  6:24               ` Amit Shah
2009-04-20  9:07                 ` Mike Galbraith
2009-04-20  9:26                   ` Jan Kara
2009-04-20 12:15                     ` Mike Galbraith
2009-04-20 12:56                       ` Amit Shah [this message]
2009-04-20 13:06                         ` Mike Galbraith
2009-04-20 13:44       ` Jan Kara
2009-04-20 14:18         ` Chris Mason
2009-04-20 14:42           ` Jan Kara
2009-04-20 14:58             ` Chris Mason
2009-04-20 15:50               ` Jan Kara
2009-04-15 19:10 ` [PATCH RFC] ext3 data=guarded v3 Eric Sandeen
2009-04-15 20:35 ` Linus Torvalds
2009-04-15 21:09   ` Theodore Tso
2009-04-16  8:44   ` Jan Kara
2009-04-16 18:09   ` Nick Piggin
2009-04-16 11:39 ` Mike Galbraith
2009-04-16 11:40   ` Mike Galbraith
2009-04-16 14:56   ` Chris Mason
2009-04-16 17:12     ` Chris Mason
2009-04-16 18:25       ` Mike Galbraith
2009-04-16 18:37       ` Linus Torvalds
2009-04-16 19:38         ` Chris Mason
2009-04-16 18:00     ` Mike Galbraith

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=20090420125653.GA28858@amit-x200.pnq.redhat.com \
    --to=amit.shah@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=efault@gmx.de \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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).