xfs
[Top] [All Lists]

Re: [PATCH v2] xfs: introduce object readahead to log recovery

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH v2] xfs: introduce object readahead to log recovery
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 1 Aug 2013 09:11:51 +1000
Cc: Zhi Yong Wu <zwu.kernel@xxxxxxxxx>, "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx>, Zhi Yong Wu <wuzhy@xxxxxxxxxxxxxxxxxx>, linux-kernel mlist <linux-kernel@xxxxxxxxxxxxxxx>, xfstests <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130731133506.GT3111@xxxxxxx>
References: <1375178347-29037-1-git-send-email-zwu.kernel@xxxxxxxxx> <20130730231155.GM13468@dastard> <CAEH94LjXRG755cTsuGN_R0V+J9aRvEJaS+0aQSAOkNWL1UbXTA@xxxxxxxxxxxxxx> <20130731133506.GT3111@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jul 31, 2013 at 08:35:07AM -0500, Ben Myers wrote:
> 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@xxxxxxxxxxxxx> wrote:
> > > On Tue, Jul 30, 2013 at 05:59:07PM +0800, zwu.kernel@xxxxxxxxx wrote:
> > >> From: Zhi Yong Wu <wuzhy@xxxxxxxxxxxxxxxxxx>
> > >>
> > >>   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@xxxxxxxxxxxxxxxxxx>
> > >> ---
> > >>  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.

Actually, it's not so much a preference but a long term code
maintenance direction. Documentation/CodingStyle says:

                        Chapter 5: Typedefs

        Please don't use things like "vps_t".

        It's a _mistake_ to use typedef for structures and pointers.
,,,,

The original XFS code inherited from Irix used typedefs, and we are
slowly removing them as we modify the code that uses the them.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>