From: Wu Fengguang <fengguang.wu@intel.com>
To: "Tang, Feng" <feng.tang@intel.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] jbd2: avoid the concurrent data writeback
Date: Mon, 15 Nov 2010 13:54:20 +0800 [thread overview]
Message-ID: <20101115055420.GA21785@localhost> (raw)
In-Reply-To: <1289827533-2576-1-git-send-email-feng.tang@intel.com>
[add CC to mailing lists]
Tang,
Good catch!
On Mon, Nov 15, 2010 at 09:25:33PM +0800, Tang, Feng wrote:
> When dd a big file to an ext4 partition, it is very likely to happen
> that both the background flush thread and kjounald try to do data
> writeback for it, and ext4_witepage may be called 100, 000 times by
> journal_submit_inode_data_buffers() without really writing one page
> back (skipped), as those pages haven't had disk blocks allocated yet.
The above changelog could show a bit more details (to help me
understand it :).
Does it happen frequently and hence has measurable overheads?
Is it safe to skip the inode? Another alternative is to wait for it:
with inode_wait_for_writeback(inode).
> This could be find by a simple test case with ftrace:
> $ sync;
> $ echo 40960 > buffer_size_kb;echo 1 > events/writeback/enable;echo 1 > events/jbd2/enable;echo 1 > events/ext4/enable;
> $ dd if=/dev/zero of=/home/test/1g.bin bs=1M count=1024;sync;
> $ cat trace > /home/test/jbd2_ext4_1g_dd.log
>
> This patch will check if the inode is under data syncing, if yes then
> don't start the writeback from kjournald
>
> Signed-off-by: Feng Tang <feng.tang@intel.com>
> ---
> fs/jbd2/commit.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> index f3ad159..8a1978d 100644
> --- a/fs/jbd2/commit.c
> +++ b/fs/jbd2/commit.c
> @@ -181,6 +181,14 @@ static int journal_submit_inode_data_buffers(struct address_space *mapping)
> .range_end = i_size_read(mapping->host),
> };
>
> + spin_lock(&inode_lock);
> + /* If this inode is under data syncing, then just quit */
Comments should go above the whole code block. And the above comment
does not really say anything. Say something *why* code like this
rather than *what* the code is doing.
> + if (mapping->host->i_state & I_SYNC) {
> + spin_unlock(&inode_lock);
> + return 0;
> + }
> + spin_unlock(&inode_lock);
> +
> ret = generic_writepages(mapping, &wbc);
> return ret;
> }
Thanks,
Fengguang
next parent reply other threads:[~2010-11-15 5:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1289827533-2576-1-git-send-email-feng.tang@intel.com>
2010-11-15 5:54 ` Wu Fengguang [this message]
2010-11-15 9:59 ` [PATCH] jbd2: avoid the concurrent data writeback Feng Tang
2010-11-15 11:27 ` Christoph Hellwig
2010-11-16 8:13 ` Feng Tang
2010-11-16 12:13 ` Jan Kara
2010-11-17 1:36 ` Feng Tang
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=20101115055420.GA21785@localhost \
--to=fengguang.wu@intel.com \
--cc=feng.tang@intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.