From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27E43C3A59E for ; Mon, 26 Aug 2019 07:17:32 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E319420874 for ; Mon, 26 Aug 2019 07:17:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="YwsKqWVJ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="MVEvXIM6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E319420874 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1i29Fr-0001tQ-9C; Mon, 26 Aug 2019 07:17:31 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1i29Fq-0001tH-3C for linux-f2fs-devel@lists.sourceforge.net; Mon, 26 Aug 2019 07:17:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:CC:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Xuac1sAokhm24Ya4Ff8Dt3resrf9ItgrGBls8W1Xq/w=; b=YwsKqWVJNKlG4zQxVYohzQ3VCh /aJMAebjlVxz60muTWfQyIGs9bI+2tWetDYeLdrLkeF9taB7+zXSd/ogZB3qdJ10Ec/xnFxSGD6xQ KVPycPs7HAifIu9ltcnzB9Lz5wv+T5bQZVoc3p0hqThTN+c8uE0JSJ4FtnC0U2Z7hpxU=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:CC:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Xuac1sAokhm24Ya4Ff8Dt3resrf9ItgrGBls8W1Xq/w=; b=MVEvXIM6o8tu8aA4U6nw1njSdJ xqeDjr5IV9tU64QC1pEcLqffTYn+P1xVsrRnxURGKZcphYACqNTC2DZccjacbCr78ZV2R2tDlCOpm dV10CAhdwpgOX4K70TzyxNbe/gFWH2rA5dnqT8q8L1uhU6yANGvfB9UnufNnqORA+ISo=; Received: from szxga04-in.huawei.com ([45.249.212.190] helo=huawei.com) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1i29Fn-00FxZA-MF for linux-f2fs-devel@lists.sourceforge.net; Mon, 26 Aug 2019 07:17:30 +0000 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7B039DC4DF080FB5E485; Mon, 26 Aug 2019 15:17:17 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.211) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 26 Aug 2019 15:17:15 +0800 To: Ju Hyung Park , Chao Yu References: <5696f35e-d91a-801a-d2bb-fbbc188bbf4c@huawei.com> From: Chao Yu Message-ID: Date: Mon, 26 Aug 2019 15:17:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Headers-End: 1i29Fn-00FxZA-MF Subject: Re: [f2fs-dev] f2fs: dirty memory increasing during gc_urgent X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net Hi Ju Hyung, On 2019/8/25 19:06, Ju Hyung Park wrote: > Hi Chao, > > On Sat, Aug 24, 2019 at 12:52 AM Chao Yu wrote: >> It's not intentional, I failed to reproduce this issue, could you add some logs >> to track why we stop urgent GC even there are still dirty segments? > > I'm pretty sure you can reproduce this issue quite easily. Oh, I just notice that my scope of data sample is too small. > > I can see this happening on multiple devices including my workstation, > laptop and my Android phone. > > Here's a simple reproduction step: > 1. Do `rm -rf * && git reset --hard` a few times under a Linux kernel Git > 2. Do a sync > 3. echo 1 > /sys/fs/f2fs/dev/gc_urgent_sleep_time > 4. echo 1 > /sys/fs/f2fs/dev/gc_urgent > 5. Once the number on "GC calls" doesn't change, look at "Dirty" under > /sys/kernel/debug/f2fs/status. It's close to 0. > 6. After doing a 'sync', "Dirty" increases a lot. > 7. Remember the number on "GC calls" and run 3 and 4 again. > 8. The number of "GC calls" increases by a few hundreds. Thank for provided test script. I found out that after data blocks migration, their parent dnodes will become dirty, so that once we execute step 6), some node segments become dirty... So after step 6), we can run 3), 4) and 6) again, "Dirty" will close to zero, that's because node blocks migration will not dirty their parent (indirect/didirect) nodes. Thanks, > > Thanks. > . > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel