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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130731231151.GD7118@dastard>
Date:	Thu, 1 Aug 2013 09:11:51 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Ben Myers <bpm@....com>
Cc:	Zhi Yong Wu <zwu.kernel@...il.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Zhi Yong Wu <wuzhy@...ux.vnet.ibm.com>,
	linux-kernel mlist <linux-kernel@...r.kernel.org>,
	xfstests <xfs@....sgi.com>
Subject: Re: [PATCH v2] xfs: introduce object readahead to log recovery

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@...morbit.com> wrote:
> > > On Tue, Jul 30, 2013 at 05:59:07PM +0800, zwu.kernel@...il.com wrote:
> > >> From: Zhi Yong Wu <wuzhy@...ux.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@...ux.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.

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@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/