All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Chris Mason <chris.mason@oracle.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	xfs@oss.sgi.com, jack@suse.cz, axboe@kernel.dk,
	dchinner@redhat.com
Subject: Re: buffered writeback torture program
Date: Thu, 21 Apr 2011 04:32:58 -0400	[thread overview]
Message-ID: <20110421083258.GA26784@infradead.org> (raw)
In-Reply-To: <1303322378-sup-1722@think>

On Wed, Apr 20, 2011 at 02:23:29PM -0400, Chris Mason wrote:
> # fsync-tester
> setting up random write file
> done setting up random write file
> starting fsync run
> starting random io!
> write time 0.0009s fsync time: 2.0142s
> write time 128.9305s fsync time: 2.6046s
> run done 2 fsyncs total, killing random writer
> 
> In this case the 128s spent in write was on a single 4K overwrite on a
> 4K file.

I can't really reproduce this locally on XFS:

setting up random write file
done setting up random write file
starting fsync run
starting random io!
write time: 0.0023s fsync time: 0.5949s
write time: 0.0605s fsync time: 0.2339s
write time: 0.0018s fsync time: 0.0179s
write time: 0.0020s fsync time: 0.0201s
write time: 0.0019s fsync time: 0.0176s
write time: 0.0018s fsync time: 0.0209s
write time: 0.0025s fsync time: 0.0197s
write time: 0.0013s fsync time: 0.0183s
write time: 0.0013s fsync time: 0.0217s
write time: 0.0016s fsync time: 0.0158s
write time: 0.0022s fsync time: 0.0240s
write time: 0.0024s fsync time: 0.0190s
write time: 0.0017s fsync time: 0.0205s
write time: 0.0030s fsync time: 0.0688s
write time: 0.0045s fsync time: 0.0193s
write time: 0.0022s fsync time: 0.0356s

But given that you are able to reproduce it, does the following patch
help your latencies?  Currently XFS actually does stop I/O when
nr_to_write reaches zero, but only for non-blocking I/O. This behaviour
was introduced in commit efceab1d563153a2b1a6e7d35376241a48126989

	"xfs: handle negative wbc->nr_to_write during sync writeback"

and works around issues in the generic writeback code.


Index: linux-2.6/fs/xfs/linux-2.6/xfs_aops.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_aops.c	2011-04-21 10:20:48.303550404 +0200
+++ linux-2.6/fs/xfs/linux-2.6/xfs_aops.c	2011-04-21 10:20:58.203496773 +0200
@@ -765,8 +765,7 @@ xfs_convert_page(
 		SetPageUptodate(page);
 
 	if (count) {
-		if (--wbc->nr_to_write <= 0 &&
-		    wbc->sync_mode == WB_SYNC_NONE)
+		if (--wbc->nr_to_write <= 0)
 			done = 1;
 	}
 	xfs_start_page_writeback(page, !page_dirty, count);

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Chris Mason <chris.mason@oracle.com>
Cc: axboe@kernel.dk, jack@suse.cz, xfs@oss.sgi.com,
	dchinner@redhat.com,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: buffered writeback torture program
Date: Thu, 21 Apr 2011 04:32:58 -0400	[thread overview]
Message-ID: <20110421083258.GA26784@infradead.org> (raw)
In-Reply-To: <1303322378-sup-1722@think>

On Wed, Apr 20, 2011 at 02:23:29PM -0400, Chris Mason wrote:
> # fsync-tester
> setting up random write file
> done setting up random write file
> starting fsync run
> starting random io!
> write time 0.0009s fsync time: 2.0142s
> write time 128.9305s fsync time: 2.6046s
> run done 2 fsyncs total, killing random writer
> 
> In this case the 128s spent in write was on a single 4K overwrite on a
> 4K file.

I can't really reproduce this locally on XFS:

setting up random write file
done setting up random write file
starting fsync run
starting random io!
write time: 0.0023s fsync time: 0.5949s
write time: 0.0605s fsync time: 0.2339s
write time: 0.0018s fsync time: 0.0179s
write time: 0.0020s fsync time: 0.0201s
write time: 0.0019s fsync time: 0.0176s
write time: 0.0018s fsync time: 0.0209s
write time: 0.0025s fsync time: 0.0197s
write time: 0.0013s fsync time: 0.0183s
write time: 0.0013s fsync time: 0.0217s
write time: 0.0016s fsync time: 0.0158s
write time: 0.0022s fsync time: 0.0240s
write time: 0.0024s fsync time: 0.0190s
write time: 0.0017s fsync time: 0.0205s
write time: 0.0030s fsync time: 0.0688s
write time: 0.0045s fsync time: 0.0193s
write time: 0.0022s fsync time: 0.0356s

But given that you are able to reproduce it, does the following patch
help your latencies?  Currently XFS actually does stop I/O when
nr_to_write reaches zero, but only for non-blocking I/O. This behaviour
was introduced in commit efceab1d563153a2b1a6e7d35376241a48126989

	"xfs: handle negative wbc->nr_to_write during sync writeback"

and works around issues in the generic writeback code.


Index: linux-2.6/fs/xfs/linux-2.6/xfs_aops.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_aops.c	2011-04-21 10:20:48.303550404 +0200
+++ linux-2.6/fs/xfs/linux-2.6/xfs_aops.c	2011-04-21 10:20:58.203496773 +0200
@@ -765,8 +765,7 @@ xfs_convert_page(
 		SetPageUptodate(page);
 
 	if (count) {
-		if (--wbc->nr_to_write <= 0 &&
-		    wbc->sync_mode == WB_SYNC_NONE)
+		if (--wbc->nr_to_write <= 0)
 			done = 1;
 	}
 	xfs_start_page_writeback(page, !page_dirty, count);

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2011-04-21  8:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-20 18:23 buffered writeback torture program Chris Mason
2011-04-20 18:23 ` Chris Mason
2011-04-20 22:06 ` Vivek Goyal
2011-04-20 22:06   ` Vivek Goyal
2011-04-21 11:09   ` Chris Mason
2011-04-21 11:09     ` Chris Mason
2011-04-21 15:25     ` Chris Mason
2011-04-21 15:25       ` Chris Mason
2011-04-21 15:35       ` Vivek Goyal
2011-04-21 15:35         ` Vivek Goyal
2011-04-21 16:55       ` Jan Kara
2011-04-21 16:55         ` Jan Kara
2011-04-21 16:57         ` Chris Mason
2011-04-21 16:57           ` Chris Mason
2011-04-21 20:44           ` Jan Kara
2011-04-21 20:44             ` Jan Kara
2011-04-21  8:32 ` Christoph Hellwig [this message]
2011-04-21  8:32   ` Christoph Hellwig
2011-04-21 17:34   ` Chris Mason
2011-04-21 17:34     ` Chris Mason
2011-04-21 17:41     ` Christoph Hellwig
2011-04-21 17:41       ` Christoph Hellwig
2011-04-21 17:59       ` Andreas Dilger
2011-04-21 17:59         ` Andreas Dilger
2011-04-21 18:02         ` Christoph Hellwig
2011-04-21 18:02           ` Christoph Hellwig
2011-04-21 18:02           ` Chris Mason
2011-04-21 18:02             ` Chris Mason
2011-04-21 18:08             ` Christoph Hellwig
2011-04-21 18:08               ` Christoph Hellwig
2011-04-21 18:29               ` Chris Mason
2011-04-21 18:29                 ` Chris Mason
2011-04-21 18:43                 ` Andreas Dilger
2011-04-21 18:43                   ` Andreas Dilger
2011-04-21 18:47                   ` Chris Mason
2011-04-21 18:47                     ` Chris Mason
2011-04-21 18:00       ` Chris Mason
2011-04-21 18:00         ` Chris Mason

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=20110421083258.GA26784@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=chris.mason@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.