Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751088AbbGDFQY (ORCPT ); Sat, 4 Jul 2015 01:16:24 -0400 Received: from mail.kernel.org ([198.145.29.136]:60379 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752969AbbGDFQN (ORCPT ); Sat, 4 Jul 2015 01:16:13 -0400 Date: Fri, 3 Jul 2015 22:16:10 -0700 From: Jaegeuk Kim To: Chao Yu Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] [PATCH 12/12] f2fs: use extent_cache by default Message-ID: <20150704051610.GC15817@jaegeuk-mac02.hsd1.ca.comcast.net> References: <1435603176-63219-1-git-send-email-jaegeuk@kernel.org> <1435603176-63219-12-git-send-email-jaegeuk@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2991 Lines: 99 Hi Chao, On Thu, Jul 02, 2015 at 08:36:16PM +0800, Chao Yu wrote: > Hi Jaegeuk, > > > -----Original Message----- > > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org] > > Sent: Tuesday, June 30, 2015 2:40 AM > > To: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org; > > linux-f2fs-devel@lists.sourceforge.net > > Cc: Jaegeuk Kim > > Subject: [f2fs-dev] [PATCH 12/12] f2fs: use extent_cache by default > > > > We don't need to handle the duplicate extent infot showrmation. > > information? Fixed. > > > > > The integrated rule is: > > - update on-disk extent with largest one tracked by in-memory extent_cache > > - destroy extent_tree for the truncation case > > - drop per-inode extent_cache by shrinker > > > > Signed-off-by: Jaegeuk Kim > > [snip] > > > @@ -538,7 +427,11 @@ static struct extent_node *__insert_extent_tree(struct f2fs_sb_info *sbi, > > } > > } > > > > - return __attach_extent_node(sbi, et, ei, parent, p); > > + en = __attach_extent_node(sbi, et, ei, parent, p); > > +update_out: > > + if (en && en->ei.len > et->largest.len) > > + et->largest = en->ei; > > IMO, it's better to update cached_en here if it is invalid in > __detach_extent_node, then cached_en and largest may point different > extent info, it can expand our region of first level extent cache. Agreed. > > [snip] > > > + > > + /* free all extent info belong to this extent tree */ > > + f2fs_destroy_extent_node(inode); > > How about returning number of freed extent node for tracing. > > node_cnt = f2fs_destroy_extent_node(inode); No problem. > > [snip] > > > @@ -237,10 +237,11 @@ void update_inode(struct inode *inode, struct page *node_page) > > ri->i_size = cpu_to_le64(i_size_read(inode)); > > ri->i_blocks = cpu_to_le64(inode->i_blocks); > > > > - read_lock(&F2FS_I(inode)->ext_lock); > > - set_raw_extent(&F2FS_I(inode)->ext, &ri->i_ext); > > - read_unlock(&F2FS_I(inode)->ext_lock); > > - > > + if (F2FS_I(inode)->extent_tree) > > Could extent cache destroy after above check? I don't think so. The extent_tree is assigned as one way. Once it is assigned, it will be deallocated only after evict_inode. Thanks, > > Thanks, > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/