Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2545448pxa; Mon, 3 Aug 2020 20:03:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCKo39IQNiGi63xIcOy7DNosK3l17gAzpX2nxRk/yPzxuGQsUTX7mAMMbQnOFj16/GtQop X-Received: by 2002:a17:906:970a:: with SMTP id k10mr19038026ejx.189.1596510218231; Mon, 03 Aug 2020 20:03:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596510218; cv=none; d=google.com; s=arc-20160816; b=imcj7D4VmKu6twE/RHxPmloYcTVQAIeM1g9Axxs+4vwEmWFeQBBHXuYvcEhaMZj/lf 9xyLqduehqwgYO6ohOa5nPjMgafIvu/LjZHiYrf/j8JSb7iTBHUPZkv9NNMZwaJ9yrrK 1GiEqoFBU0nigKGb/LaucC8425WYVlyPtUEb3gpQTB7/hiNhjisd48Rr7aYszqZWvRNa Q6fh+6yorE9iscvO4mJ+bMabNPEDQfg0vZUUdFqgKzBt92ZUFgnx2Fi/63/PEdYDu1Sc rnHBVHHPRFAY0pzveHTshvseiRMfSS0FyHpVIDRWQL3IDUW4ZEIt33orWwoNpmv9A43M 7YYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=eMKyh14Lc6+nPXxL7wlBbtrcQpSoLF88ek7gMgIpNxE=; b=dgtHImOnRT4VPz9Lk42D/IuVHrWSIt4hYuLUb5xrcGNHgGKXD1//otMXhMVBtQmamJ ual1hgz3EsUi6nGqPAPQfp3qCF2TTN4W3vsYC9bCEq+KyFFP/Nusu/BW8b/Nve54LRIM 7e7zoSxQJcJ71B22AhP+SmktNxTL/t4xjB9DDoBKwP+le1U48D/zfn3aeEiit/NfsoCi uCgLz485zJgalobkZqiqm5E7nOGSRgmIX3BIPnMF+qYBM/IHdpnUDGwv3ZDblCdXIn2t j64p/Uff143dPW3B74v56867mSUHGlg2C7s0KvZJm3DpIDvDG9jbBonlV1ZUNXPY7lmA aqgQ== 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 a13si11464328edy.381.2020.08.03.20.03.13; Mon, 03 Aug 2020 20:03:38 -0700 (PDT) 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 S1727060AbgHDDAI (ORCPT + 99 others); Mon, 3 Aug 2020 23:00:08 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:9324 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725840AbgHDDAI (ORCPT ); Mon, 3 Aug 2020 23:00:08 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 2119C2BC0355340BEDBF; Tue, 4 Aug 2020 11:00:06 +0800 (CST) Received: from [10.164.122.247] (10.164.122.247) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 4 Aug 2020 11:00:01 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: remove a waiter for checkpoint completion To: Jaegeuk Kim CC: , , , Eric Biggers References: <20200803172825.4077289-1-jaegeuk@kernel.org> <9638d2c5-cfd0-359f-187a-8e23bc6d822d@huawei.com> <20200804010412.GA866340@google.com> <98ac9355-bb6c-5109-da73-4ab7cdbbf8d5@huawei.com> <20200804024317.GA884736@google.com> From: Chao Yu Message-ID: <6d84bfea-13a3-af84-16ad-5d0c7eedeb67@huawei.com> Date: Tue, 4 Aug 2020 11:00:01 +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: <20200804024317.GA884736@google.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.164.122.247] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/4 10:43, Jaegeuk Kim wrote: > On 08/04, Chao Yu wrote: >> On 2020/8/4 9:04, Jaegeuk Kim wrote: >>> On 08/04, Chao Yu wrote: >>>> On 2020/8/4 1:28, Jaegeuk Kim wrote: >>>>> It doesn't need to wait for checkpoint being completed triggered by end_io. >>>>> >>>>> [ 20.157753] ------------[ cut here ]------------ >>>>> [ 20.158393] do not call blocking ops when !TASK_RUNNING; state=2 set at [<0000000096354225>] prepare_to_wait+0xcd/0x430 >>>>> [ 20.159858] WARNING: CPU: 1 PID: 1152 at kernel/sched/core.c:7142 __might_sleep+0x149/0x1a0 >>>>> ... >>>>> [ 20.176110] __submit_merged_write_cond+0x191/0x310 >>>>> [ 20.176739] f2fs_submit_merged_write+0x18/0x20 >>>>> [ 20.177323] f2fs_wait_on_all_pages+0x269/0x2d0 >>>>> [ 20.177899] ? block_operations+0x980/0x980 >>>>> [ 20.178441] ? __kasan_check_read+0x11/0x20 >>>>> [ 20.178975] ? finish_wait+0x260/0x260 >>>>> [ 20.179488] ? percpu_counter_set+0x147/0x230 >>>>> [ 20.180049] do_checkpoint+0x1757/0x2a50 >>>>> [ 20.180558] f2fs_write_checkpoint+0x840/0xaf0 >>>>> [ 20.181126] f2fs_sync_fs+0x287/0x4a0 >>>>> >>>>> Reported-by: Eric Biggers >>>>> Signed-off-by: Jaegeuk Kim >>>>> --- >>>>> fs/f2fs/checkpoint.c | 6 +----- >>>>> fs/f2fs/data.c | 4 ---- >>>>> fs/f2fs/f2fs.h | 1 - >>>>> fs/f2fs/super.c | 1 - >>>>> 4 files changed, 1 insertion(+), 11 deletions(-) >>>>> >>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >>>>> index 99c8061da55b9..2bdddc725e677 100644 >>>>> --- a/fs/f2fs/checkpoint.c >>>>> +++ b/fs/f2fs/checkpoint.c >>>>> @@ -1255,11 +1255,7 @@ static void unblock_operations(struct f2fs_sb_info *sbi) >>>>> void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int type) >>>>> { >>>>> - DEFINE_WAIT(wait); >>>>> - >>>>> for (;;) { >>>>> - prepare_to_wait(&sbi->cp_wait, &wait, TASK_UNINTERRUPTIBLE); >>>> >>>> Wouldn't that case high cpu usage before io end? >>> >>> This is a critical path to wait for IO completion in checkpoint, which would be >>> better to wait for it to avoid long latency to continue filesystem operations. >> >> Yup, in previous implementation, last end_io wakes up checkpoint() waiter, we >> didn't waste any time there. >> >>> Moreover, I expect io_schedule_timeout() can mitigate such the CPU overhead and >>> actually we don't need to make there-in context switches as well. >> >> Then io_schedule_timeout() in this loop may give CPU time slice to other thread >> until scheduler reselect checkpoint(), that would cause longer latency? > > Hmm, how about this then? > >>From 4956afa1cedc019cabf6e8bff7bc48d3bcf7a3f5 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim > Date: Mon, 3 Aug 2020 19:37:12 -0700 > Subject: [PATCH] f2fs: prepare a waiter before entering io_schedule > > This is to avoid sleep() in the waiter thread. > > [ 20.157753] ------------[ cut here ]------------ > [ 20.158393] do not call blocking ops when !TASK_RUNNING; state=2 set at [<0000000096354225>] prepare_to_wait+0xcd/0x430 > [ 20.159858] WARNING: CPU: 1 PID: 1152 at kernel/sched/core.c:7142 __might_sleep+0x149/0x1a0 > ... > [ 20.176110] __submit_merged_write_cond+0x191/0x310 > [ 20.176739] f2fs_submit_merged_write+0x18/0x20 > [ 20.177323] f2fs_wait_on_all_pages+0x269/0x2d0 > [ 20.177899] ? block_operations+0x980/0x980 > [ 20.178441] ? __kasan_check_read+0x11/0x20 > [ 20.178975] ? finish_wait+0x260/0x260 > [ 20.179488] ? percpu_counter_set+0x147/0x230 > [ 20.180049] do_checkpoint+0x1757/0x2a50 > [ 20.180558] f2fs_write_checkpoint+0x840/0xaf0 > [ 20.181126] f2fs_sync_fs+0x287/0x4a0 > > Reported-by: Eric Biggers > Signed-off-by: Jaegeuk Kim Better, Reviewed-by: Chao Yu Thanks, > --- > fs/f2fs/checkpoint.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > index 99c8061da55b9..ff807e14c8911 100644 > --- a/fs/f2fs/checkpoint.c > +++ b/fs/f2fs/checkpoint.c > @@ -1258,8 +1258,6 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int type) > DEFINE_WAIT(wait); > > for (;;) { > - prepare_to_wait(&sbi->cp_wait, &wait, TASK_UNINTERRUPTIBLE); > - > if (!get_pages(sbi, type)) > break; > > @@ -1271,6 +1269,8 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int type) > FS_CP_META_IO); > else if (type == F2FS_WB_CP_DATA) > f2fs_submit_merged_write(sbi, DATA); > + > + prepare_to_wait(&sbi->cp_wait, &wait, TASK_UNINTERRUPTIBLE); > io_schedule_timeout(DEFAULT_IO_TIMEOUT); > } > finish_wait(&sbi->cp_wait, &wait); >