Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753767AbbGBMjr (ORCPT ); Thu, 2 Jul 2015 08:39:47 -0400 Received: from col004-omc1s10.hotmail.com ([65.55.34.20]:63109 "EHLO COL004-OMC1S10.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753791AbbGBMiU (ORCPT ); Thu, 2 Jul 2015 08:38:20 -0400 X-TMN: [C1EO4BvvssZfFy82cgS9iQEig2Va/uCh] X-Originating-Email: [yuchaochina@hotmail.com] Message-ID: From: Chao Yu To: "'Jaegeuk Kim'" CC: , , References: <1435603176-63219-1-git-send-email-jaegeuk@kernel.org> <1435603176-63219-12-git-send-email-jaegeuk@kernel.org> In-Reply-To: <1435603176-63219-12-git-send-email-jaegeuk@kernel.org> Subject: RE: [f2fs-dev] [PATCH 12/12] f2fs: use extent_cache by default Date: Thu, 2 Jul 2015 20:36:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-index: AQABAgMEiGO+4tzbXpkKS0JOaLu9TKFnO3uQ Content-Language: zh-cn X-OriginalArrivalTime: 02 Jul 2015 12:36:20.0781 (UTC) FILETIME=[B2F5A5D0:01D0B4C3] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2073 Lines: 68 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? > > 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. [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); [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? Thanks, -- 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/