From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754879AbdBHPZo (ORCPT ); Wed, 8 Feb 2017 10:25:44 -0500 Received: from mail.kernel.org ([198.145.29.136]:51792 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753221AbdBHPZk (ORCPT ); Wed, 8 Feb 2017 10:25:40 -0500 Subject: Re: [PATCH] f2fs: introduce nid cache To: Chao Yu , Jaegeuk Kim References: <20170122095331.58427-1-yuchao0@huawei.com> <20170124043500.GC1566@jaegeuk.local> <452624a9-8b9a-843c-98df-00187a8f795a@huawei.com> Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org From: Chao Yu Message-ID: <5c8999e9-f405-7e23-0d1a-209b24f040d8@kernel.org> Date: Wed, 8 Feb 2017 23:25:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <452624a9-8b9a-843c-98df-00187a8f795a@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/2/7 15:24, Chao Yu wrote: > Hi Jaegeuk, > > Happy Chinese New Year! :) > > On 2017/1/24 12:35, Jaegeuk Kim wrote: >> Hi Chao, >> >> On 01/22, Chao Yu wrote: >>> In scenario of intensively node allocation, free nids will be ran out >>> soon, then it needs to stop to load free nids by traversing NAT blocks, >>> in worse case, if NAT blocks does not be cached in memory, it generates >>> IOs which slows down our foreground operations. >>> >>> In order to speed up node allocation, in this patch we introduce a new >>> option named "nid cache", when turns on this option, it will load all >>> nat entries in NAT blocks when doing mount, and organize all free nids >>> in a bitmap, for any operations related to free nid, we will query and >>> set the new prebuilded bitmap instead of reading and lookuping NAT >>> blocks, so performance of node allocation can be improved. >>> >> >> How does this affect mount time and memory consumption? > > Sorry for the delay. > > Let me figure out some numbers later. a. mount time I choose slow device (Kingston 16GB SD card) to see how this option affect mount time when there is not enough bandwidth in low level, Before the test, I change readahead window size of NAT pages from FREE_NID_PAGES * 8 to sbi->blocks_per_seg for better ra performance, so the result is: time mount -t f2fs -o nid_cache /dev/sde /mnt/f2fs/ before: real 0m0.204s user 0m0.004s sys 0m0.020s after: real 0m3.792s user 0m0.000s sys 0m0.140s b. memory consumption For 16GB size image, there is total 34 NAT pages, so memory footprint is: 34 / 2 * 512 * 455 / 8 = 495040 bytes = 483.4 KB Increasing of memory footprint is liner with total user valid blocks in image, and at most it will eat 3900 * 8 * 455 / 8 = 1774500 bytes = 1732.9 KB Thanks, > >> IMO, if those do not >> raise huge concerns, we would be able to consider just replacing current free >> nid list with this bitmap. > > Yup, I agree with you. > > Thanks, >