From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1CF5C7CBF for ; Wed, 31 Jul 2013 18:12:00 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E1F323040BF for ; Wed, 31 Jul 2013 16:11:56 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id NAqy8oIxj7APZrBt for ; Wed, 31 Jul 2013 16:11:55 -0700 (PDT) Date: Thu, 1 Aug 2013 09:11:51 +1000 From: Dave Chinner Subject: Re: [PATCH v2] xfs: introduce object readahead to log recovery Message-ID: <20130731231151.GD7118@dastard> References: <1375178347-29037-1-git-send-email-zwu.kernel@gmail.com> <20130730231155.GM13468@dastard> <20130731133506.GT3111@sgi.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130731133506.GT3111@sgi.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Ben Myers Cc: Zhi Yong Wu , "linux-fsdevel@vger.kernel.org" , Zhi Yong Wu , linux-kernel mlist , xfstests 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 wrote: > > > On Tue, Jul 30, 2013 at 05:59:07PM +0800, zwu.kernel@gmail.com wrote: > > >> From: Zhi Yong Wu > > >> > > >> 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 > > >> --- > > >> 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@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs