From: Ben Myers <bpm@sgi.com>
To: Zhi Yong Wu <zwu.kernel@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>,
linux-kernel mlist <linux-kernel@vger.kernel.org>,
xfstests <xfs@oss.sgi.com>
Subject: Re: [PATCH v2] xfs: introduce object readahead to log recovery
Date: Wed, 31 Jul 2013 08:35:07 -0500 [thread overview]
Message-ID: <20130731133506.GT3111@sgi.com> (raw)
In-Reply-To: <CAEH94LjXRG755cTsuGN_R0V+J9aRvEJaS+0aQSAOkNWL1UbXTA@mail.gmail.com>
Hey Zhi,
On Wed, Jul 31, 2013 at 12:07:32PM +0800, Zhi Yong Wu wrote:
> On Wed, Jul 31, 2013 at 7:11 AM, Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, Jul 30, 2013 at 05:59:07PM +0800, zwu.kernel@gmail.com wrote:
> >> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
> >>
> >> It can take a long time to run log recovery operation because it is
> >> single threaded and is bound by read latency. We can find that it took
> >> most of the time to wait for the read IO to occur, so if one object
> >> readahead is introduced to log recovery, it will obviously reduce the
> >> log recovery time.
> >>
> >> Log recovery time stat:
> >>
> >> w/o this patch w/ this patch
> >>
> >> real: 0m15.023s 0m7.802s
> >> user: 0m0.001s 0m0.001s
> >> sys: 0m0.246s 0m0.107s
> >>
> >> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
> >> ---
> >> fs/xfs/xfs_log_recover.c | 162 +++++++++++++++++++++++++++++++++++++++++++++--
> >> fs/xfs/xfs_log_recover.h | 2 +
> >> 2 files changed, 159 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> >> index 7681b19..029826f 100644
> >> --- a/fs/xfs/xfs_log_recover.c
> >> +++ b/fs/xfs/xfs_log_recover.c
> >> @@ -3116,6 +3116,111 @@ xlog_recover_free_trans(
> >> kmem_free(trans);
> >> }
> >>
> >> +STATIC void
> >> +xlog_recover_buffer_ra_pass2(
> >> + struct xlog *log,
> >> + struct xlog_recover_item *item)
> >> +{
> >> + xfs_buf_log_format_t *buf_f = item->ri_buf[0].i_addr;
> >> + xfs_mount_t *mp = log->l_mp;
> >
> > struct xfs_buf_log_format
> > struct xfs_mount
> Why? *_t is also used in a lot of other places.
It is just a general style preference for using the struct instead of the _t in
the xfs codebase. Over the course of the past few years they've slowly been
converted in this direction, and we prefer not to add any more _t if it can be
avoided.
-Ben
next prev parent reply other threads:[~2013-07-31 13:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 9:59 [PATCH v2] xfs: introduce object readahead to log recovery zwu.kernel
2013-07-30 13:10 ` Brian Foster
2013-07-30 22:36 ` Zhi Yong Wu
2013-07-30 23:11 ` Dave Chinner
2013-07-31 4:07 ` Zhi Yong Wu
2013-07-31 13:35 ` Ben Myers [this message]
2013-07-31 14:17 ` Zhi Yong Wu
2013-07-31 23:11 ` 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=20130731133506.GT3111@sgi.com \
--to=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wuzhy@linux.vnet.ibm.com \
--cc=xfs@oss.sgi.com \
--cc=zwu.kernel@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