Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2511814pxb; Mon, 18 Jan 2021 21:44:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwKYGBKaMue8kvdnBFCVaVR1BgvexHXIYl2TKM5N6HQqc5bd8dBeAbi5CC8hCSoNjFYDPVv X-Received: by 2002:a05:6402:31b5:: with SMTP id dj21mr2173945edb.90.1611035069886; Mon, 18 Jan 2021 21:44:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611035069; cv=none; d=google.com; s=arc-20160816; b=Klv6LEu37Pxr8o0rxlq1MvUUnLxLlvbb0g2ykSegJLHHqmaFSMMBDjqGbwLrrdfrb5 e3fa7Z1OdUjUiX7Cg7wC+SNSJfZn4m9e00ljzPFGcRga1XwTazDusOorEuYIwyMBGEHo tlwfQ6VM+ZoKG3UQAk/GbpCfo80z4kSEfdqpFaVUbRmHILxuAb2OxYUVDBYC/W/UCtk0 f42rktOUbDg/kl89LBvkKGEkdlirMLLYifJKyCisJzYB/0i5cxww5DbUCZNfVOu3ZTvr 8IWi6fclf5sdY/yPQc8QW6+ngGDxnrF+7YH3tzUMLboinFjON9/XxF6xlmlbwQr40f6o BQyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=c5Mo8/SO/ldmO3EgAd4HYQmbjcGmYLlzsX+KjPJKqwI=; b=nX/n4pa27ATNqJnslebZmXKnTAgxUN+CrPzqQ5zeKFtD8WucyzWsOko+I9JVgiJqAh Uo1w5zQyRC95V1emekTcqVVxMY1PJgvVReAdMmIfGFacuGegIJOhA+6BkpZ8hg8scAJA vQYGXhJtYLUBhe02rgeCUYyxAx1e76GWfzirQGoqx+nOgFR2DY6NYbwNzsqBc4nIHhUx fDaD2D+iTZqEOdvbk3Sh/ZiksRYpwjip5gbLsy/Qk4W0i78+tactlAxfoB6Gajgs/mhg ntXfzuxoqiSgkz4W4mr1n1Fq4PlP+IwzcxC+Ro3cvhaPvN4DOlYUHRb/8jd5Yr8xsPIg PIfg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y22si8352763ejc.25.2021.01.18.21.44.07; Mon, 18 Jan 2021 21:44:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387909AbhASCiY (ORCPT + 99 others); Mon, 18 Jan 2021 21:38:24 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11173 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394305AbhASChU (ORCPT ); Mon, 18 Jan 2021 21:37:20 -0500 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DKXnG4S31zl6Dj; Tue, 19 Jan 2021 10:35:14 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.214) with Microsoft SMTP Server (TLS) id 14.3.498.0; Tue, 19 Jan 2021 10:36:34 +0800 Subject: Re: [f2fs-dev] [PATCH v4 1/2] f2fs: introduce checkpoint=merge mount option To: Daeho Jeong , , , CC: Sungjong Seo , Daeho Jeong References: <20210119000043.1206345-1-daeho43@gmail.com> From: Chao Yu Message-ID: Date: Tue, 19 Jan 2021 10:36:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20210119000043.1206345-1-daeho43@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/1/19 8:00, Daeho Jeong wrote: > From: Daeho Jeong > > We've added a new mount option "checkpoint=merge", which creates a > kernel daemon and makes it to merge concurrent checkpoint requests as > much as possible to eliminate redundant checkpoint issues. Plus, we > can eliminate the sluggish issue caused by slow checkpoint operation > when the checkpoint is done in a process context in a cgroup having > low i/o budget and cpu shares. To make this do better, we set the > default i/o priority of the kernel daemon to "3", to give one higher > priority than other kernel threads. The below verification result > explains this. > The basic idea has come fromhttps://opensource.samsung.com. > > [Verification] > Android Pixel Device(ARM64, 7GB RAM, 256GB UFS) > Create two I/O cgroups (fg w/ weight 100, bg w/ wight 20) > Set "strict_guarantees" to "1" in BFQ tunables > > In "fg" cgroup, > - thread A => trigger 1000 checkpoint operations > "for i in `seq 1 1000`; do touch test_dir1/file; fsync test_dir1; > done" > - thread B => gererating async. I/O > "fio --rw=write --numjobs=1 --bs=128k --runtime=3600 --time_based=1 > --filename=test_img --name=test" > > In "bg" cgroup, > - thread C => trigger repeated checkpoint operations > "echo $$ > /dev/blkio/bg/tasks; while true; do touch test_dir2/file; > fsync test_dir2; done" > > We've measured thread A's execution time. > > [ w/o patch ] > Elapsed Time: Avg. 68 seconds > [ w/ patch ] > Elapsed Time: Avg. 48 seconds > > Signed-off-by: Daeho Jeong > Signed-off-by: Sungjong Seo Reviewed-by: Chao Yu Thanks,