Re: [PATCH 1/3] nilfs2: remove nilfs_segctor_init() in segment.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, go ahead :)

Thanks,
Li Hong

On Sun, Apr 11, 2010 at 04:58:47PM +0900, Ryusuke Konishi wrote:
> On Sun, 11 Apr 2010 12:17:26 +0800, Li Hong <lihong.hi@xxxxxxxxx> wrote:
> > On Sun, Apr 11, 2010 at 02:57:15AM +0900, Ryusuke Konishi wrote:
> > > Hi,
> > > On Sun, 11 Apr 2010 00:15:43 +0800, Li Hong <lihong.hi@xxxxxxxxx> wrote:
> > > > Hi KONISHI Ryusuke,
> > > > 
> > > > Three new patches based on nilfs2/for-next branch. New code has been built and
> > > > loaded successfully, and also passed a light-weight reads and writes test.
> > > > 
> > > > Thanks,
> > > > Li Hong
> > > 
> > > Ok, I'll look into each of them.
> > > 
> > > > ---------------------------- cut here --------------------------
> > > > 
> > > > From 2c622d0f59782321204bf1fde7eea4a593cc6b65 Mon Sep 17 00:00:00 2001
> > > > From: Li Hong <lihong.hi@xxxxxxxxx>
> > > > Date: Sat, 10 Apr 2010 21:57:11 +0800
> > > > Subject: [PATCH 1/3] nilfs2: remove nilfs_segctor_init() in segment.c
> > > > 
> > > > There are only two lines of code in nilfs_segctor_init(). From a logic design
> > > > view, the first line 'sci->sc_seq_done = sci->sc_seq_request;' should be put in
> > > > nilfs_segctor_new(). Even in nilfs_segctor_new(), this initialization is
> > > > needless because sci is kzalloc-ed. So nilfs_segctor_init() is only a wrap call
> > > > to nilfs_segctor_start_thread(). This removes an indirect call overhead.
> > > > 
> > > > Signed-off-by: Li Hong <lihong.hi@xxxxxxxxx>
> > > 
> > > Looks no problem.
> > > 
> > > The reason why nilfs_segctor_init is present in that manner is
> > > historical (just for your information. You don't have to mention this
> > > reason).
> > > 
> > > I think you don't have to mention the indirect call overhead because
> > > it's only triggered in the level of mount/unmount/remount and gcc will
> > > inline it in the caller.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> > No, there is no inline key word in nilfs_segctor_init().
> 
> > Unless you mean gcc will try to inline small procedures if possible.
> 
> I mean this ;)
> 
> By "objdump -D segment.o", you can actually see the function is
> inlined in the caller.  It's a default thing nowadays unless
> "noinline" keyword is specified.
> 
> Anyway, the only point I feel odd is the description.  Basically, I'd
> like to apply this patch for cleanup.  May I remove the comment "this
> removes an indrect call oveahead"?
> 
> Thanks,
> Ryusuke Konishi
> 
> > Thanks,
> > Li Hong
> > 
> > > Thanks,
> > > Ryusuke Konishi
> > > 
> > > > ---
> > > >  fs/nilfs2/segment.c |    9 +--------
> > > >  1 files changed, 1 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c
> > > > index f235fc0..514620d 100644
> > > > --- a/fs/nilfs2/segment.c
> > > > +++ b/fs/nilfs2/segment.c
> > > > @@ -2684,13 +2684,6 @@ static void nilfs_segctor_kill_thread(struct nilfs_sc_info *sci)
> > > >  	}
> > > >  }
> > > >  
> > > > -static int nilfs_segctor_init(struct nilfs_sc_info *sci)
> > > > -{
> > > > -	sci->sc_seq_done = sci->sc_seq_request;
> > > > -
> > > > -	return nilfs_segctor_start_thread(sci);
> > > > -}
> > > > -
> > > >  /*
> > > >   * Setup & clean-up functions
> > > >   */
> > > > @@ -2814,7 +2807,7 @@ int nilfs_attach_segment_constructor(struct nilfs_sb_info *sbi)
> > > >  		return -ENOMEM;
> > > >  
> > > >  	nilfs_attach_writer(nilfs, sbi);
> > > > -	err = nilfs_segctor_init(NILFS_SC(sbi));
> > > > +	err = nilfs_segctor_start_thread(NILFS_SC(sbi));
> > > >  	if (err) {
> > > >  		nilfs_detach_writer(nilfs, sbi);
> > > >  		kfree(sbi->s_sc_info);
> > > > -- 
> > > > 1.6.3.3
> > > > 
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> > > > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux BTRFS]     [Linux CIFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux