From: Jan Kara <jack@suse.cz>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@linux.vnet.ibm.com>, Mel Gorman <mel@csn.ul.ie>,
Dave Chinner <david@fromorbit.com>,
Itaru Kitayama <kitayama@cl.bb4u.ne.jp>,
Minchan Kim <minchan.kim@gmail.com>,
Linux Memory Management List <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] writeback: refill b_io iff empty
Date: Fri, 6 May 2011 16:21:55 +0200 [thread overview]
Message-ID: <20110506142155.GD18982@quack.suse.cz> (raw)
In-Reply-To: <20110506052955.GA24904@localhost>
On Fri 06-05-11 13:29:55, Wu Fengguang wrote:
> On Fri, May 06, 2011 at 12:37:08AM +0800, Jan Kara wrote:
> > On Wed 04-05-11 15:39:31, Wu Fengguang wrote:
> > > To help understand the behavior change, I wrote the writeback_queue_io
> > > trace event, and found very different patterns between
> > > - vanilla kernel
> > > - this patchset plus the sync livelock fixes
> > >
> > > Basically the vanilla kernel each time pulls a random number of inodes
> > > from b_dirty, while the patched kernel tends to pull a fixed number of
> > > inodes (enqueue=1031) from b_dirty. The new behavior is very interesting...
> > This regularity is really strange. Did you have a chance to look more into
> > it? I find it highly unlikely that there would be exactly 1031 dirty inodes
> > in b_dirty list every time you call move_expired_inodes()...
>
> Jan, I got some results for ext4. The total dd+tar+sync time is
> decreased from 177s to 167s. The other numbers are either raised or
> dropped.
Nice, but what I was more curious about was to understand why you saw
enqueued=1031 all the time. BTW, I'd suppose that the better performance
numbers come from sync using page tagging, right? Because from the traces
it seems that not much IO is going on until sync is called. And I expect
that tagging can bring you some performance because now you sync a file in
one big sweep instead of 4MB chunks...
> 1902.672610: writeback_queue_io: older=4296543506 age=30000 enqueue=0
> 1905.209570: writeback_queue_io: older=4296546051 age=30000 enqueue=0
> 1907.294936: writeback_queue_io: older=4296548143 age=30000 enqueue=0
> 1909.607301: writeback_queue_io: older=4296550462 age=30000 enqueue=0
> 1912.290627: writeback_queue_io: older=4296553154 age=30000 enqueue=0
> 1914.331197: writeback_queue_io: older=4296555201 age=30000 enqueue=0
> 1927.275838: writeback_queue_io: older=4296568186 age=30000 enqueue=0
> 1927.277794: writeback_queue_io: older=4296568188 age=30000 enqueue=0
> 1927.279504: writeback_queue_io: older=4296568189 age=30000 enqueue=0
> 1927.279923: writeback_queue_io: older=4296568190 age=30000 enqueue=0
> 1929.981734: writeback_queue_io: older=4296600898 age=2 enqueue=13227
> 1932.840150: writeback_queue_io: older=4296600898 age=2869 enqueue=0
> 1932.840781: writeback_queue_io: older=4296603768 age=0 enqueue=0
> 1932.840787: writeback_queue_io: older=4296573768 age=30000 enqueue=0
> 1932.991596: writeback_queue_io: older=4296603919 age=0 enqueue=1
> 1937.975765: writeback_queue_io: older=4296578919 age=30000 enqueue=0
> 1942.960305: writeback_queue_io: older=4296583919 age=30000 enqueue=0
> 1947.944925: writeback_queue_io: older=4296588919 age=30000 enqueue=0
> 1952.929427: writeback_queue_io: older=4296593919 age=30000 enqueue=0
> 1957.914031: writeback_queue_io: older=4296598919 age=30000 enqueue=0
> 1962.898507: writeback_queue_io: older=4296603919 age=30000 enqueue=1
> 1962.898518: writeback_queue_io: older=4296603919 age=30000 enqueue=0
OK, so now enqueue numbers look like what I'd expect. I'm relieved :)
Thanks for running the tests.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2011-05-06 14:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 8:03 [PATCH 0/6] writeback: moving expire targets for background/kupdate works v2 Wu Fengguang
2011-04-20 8:03 ` [PATCH 1/6] writeback: pass writeback_control down to move_expired_inodes() Wu Fengguang
2011-05-04 11:04 ` Christoph Hellwig
2011-05-04 11:13 ` Wu Fengguang
2011-04-20 8:03 ` [PATCH 2/6] writeback: introduce writeback_control.inodes_cleaned Wu Fengguang
2011-05-04 11:05 ` Christoph Hellwig
2011-05-04 11:11 ` Wu Fengguang
2011-05-04 11:16 ` Christoph Hellwig
2011-05-04 11:32 ` Wu Fengguang
2011-04-20 8:03 ` [PATCH 3/6] writeback: try more writeback as long as something was written Wu Fengguang
2011-04-20 8:03 ` [PATCH 4/6] writeback: the kupdate expire timestamp should be a moving target Wu Fengguang
2011-04-20 8:03 ` [PATCH 5/6] writeback: sync expired inodes first in background writeback Wu Fengguang
2011-04-20 23:40 ` Andrew Morton
2011-04-21 1:14 ` Wu Fengguang
2011-04-21 1:21 ` Wu Fengguang
2011-04-24 3:15 ` Wu Fengguang
2011-04-26 12:17 ` Jan Kara
2011-04-26 13:51 ` Wu Fengguang
2011-04-26 13:59 ` Wu Fengguang
2011-04-26 14:05 ` Wu Fengguang
2011-04-27 11:15 ` Wu Fengguang
2011-04-20 8:03 ` [PATCH 6/6] writeback: refill b_io iff empty Wu Fengguang
2011-05-04 7:39 ` Wu Fengguang
2011-05-05 16:37 ` Jan Kara
2011-05-05 16:47 ` Wu Fengguang
2011-05-06 5:29 ` Wu Fengguang
2011-05-06 8:42 ` [RFC][PATCH] writeback: limit number of moved inodes in queue_io() Wu Fengguang
2011-05-06 10:06 ` [RFC][PATCH v2] " Wu Fengguang
2011-05-06 23:06 ` Dave Chinner
2011-05-06 14:21 ` Jan Kara [this message]
2011-05-10 4:31 ` [PATCH 6/6] writeback: refill b_io iff empty Wu Fengguang
2011-05-10 4:53 ` Dave Chinner
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=20110506142155.GD18982@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=kitayama@cl.bb4u.ne.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mel@linux.vnet.ibm.com \
--cc=minchan.kim@gmail.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 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).