From patchwork Thu Mar 9 11:22:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hou Tao X-Patchwork-Id: 9613101 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7D09560414 for ; Thu, 9 Mar 2017 11:23:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7885D285E8 for ; Thu, 9 Mar 2017 11:23:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6D644285F5; Thu, 9 Mar 2017 11:23:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CD31E285E8 for ; Thu, 9 Mar 2017 11:23:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754457AbdCILXl (ORCPT ); Thu, 9 Mar 2017 06:23:41 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:4286 "EHLO dggrg01-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753432AbdCILXi (ORCPT ); Thu, 9 Mar 2017 06:23:38 -0500 Received: from 172.30.72.53 (EHLO DGGEML404-HUB.china.huawei.com) ([172.30.72.53]) by dggrg01-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AKM49973; Thu, 09 Mar 2017 19:22:34 +0800 (CST) Received: from [127.0.0.1] (10.177.31.14) by DGGEML404-HUB.china.huawei.com (10.3.17.39) with Microsoft SMTP Server id 14.3.301.0; Thu, 9 Mar 2017 19:22:29 +0800 Subject: Re: [PATCH v2] cfq-iosched: fix the delay of cfq_group's vdisktime under iops mode To: Jan Kara , References: <1488975415-40417-1-git-send-email-houtao1@huawei.com> <20170308140518.GE19740@quack2.suse.cz> CC: , , , From: Hou Tao Message-ID: Date: Thu, 9 Mar 2017 19:22:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170308140518.GE19740@quack2.suse.cz> X-Originating-IP: [10.177.31.14] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58C13AFC.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 18ace19aca792d411a400492db5de3e1 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2017/3/8 22:05, Jan Kara wrote: > On Wed 08-03-17 20:16:55, Hou Tao wrote: >> When adding a cfq_group into the cfq service tree, we use CFQ_IDLE_DELAY >> as the delay of cfq_group's vdisktime if there have been other cfq_groups >> already. >> >> When cfq is under iops mode, commit 9a7f38c42c2b ("cfq-iosched: Convert >> from jiffies to nanoseconds") could result in a large iops delay and >> lead to an abnormal io schedule delay for the added cfq_group. To fix >> it, we just need to revert to the old CFQ_IDLE_DELAY value: HZ / 5 >> when iops mode is enabled. >> >> Despite having the same value, the delay of a cfq_queue in idle class >> and the delay of cfq_queue are different things, so I define two new >> macros for the delay of a cfq_group under time-slice mode and IOPs mode. >> >> Fixes: 9a7f38c42c2b92391d9dabaf9f51df7cfe5608e4 >> Cc: # 4.8+ >> Signed-off-by: Hou Tao > > OK, the number 200 is somewhat arbitrary but so is HZ/5 so I guess we are > OK. You can add: > > Acked-by: Jan Kara Oops, sorry for the arbitrary 200. My intention was to use HZ / 5 instead of 200 to keep consistent with the old CFQ_IDLE_DELAY. And I spot two typos in commit message: "the delay of cfq_queue" -> "the delay of cfq_group" and "IOPs" -> "iops". Jan, could you please fix them ? And I also attach a revised patch to fix them. From: Hou Tao Date: Wed, 1 Mar 2017 09:02:33 +0800 Subject: [PATCH] cfq-iosched: fix the delay of cfq_group's vdisktime under iops mode When adding a cfq_group into the cfq service tree, we use CFQ_IDLE_DELAY as the delay of cfq_group's vdisktime if there have been other cfq_groups already. When cfq is under iops mode, commit 9a7f38c42c2b ("cfq-iosched: Convert from jiffies to nanoseconds") could result in a large iops delay and lead to an abnormal io schedule delay for the added cfq_group. To fix it, we just need to revert to the old CFQ_IDLE_DELAY value: HZ / 5 when iops mode is enabled. Despite having the same value, the delay of a cfq_queue in idle class and the delay of cfq_group are different things, so I define two new macros for the delay of a cfq_group under time-slice mode and iops mode. Fixes: 9a7f38c42c2b92391d9dabaf9f51df7cfe5608e4 Cc: # 4.8+ Signed-off-by: Hou Tao Acked-by: Jan Kara --- block/cfq-iosched.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c index 440b95e..2762505 100644 --- a/block/cfq-iosched.c +++ b/block/cfq-iosched.c @@ -38,9 +38,13 @@ static const u64 cfq_target_latency = (u64)NSEC_PER_SEC * 3/10; /* 300 ms */ static const int cfq_hist_divisor = 4; /* - * offset from end of service tree + * offset from end of queue service tree for idle class */ #define CFQ_IDLE_DELAY (NSEC_PER_SEC / 5) +/* offset from end of group service tree under time slice mode */ +#define CFQ_SLICE_MODE_GROUP_DELAY (NSEC_PER_SEC / 5) +/* offset from end of group service under IOPS mode */ +#define CFQ_IOPS_MODE_GROUP_DELAY (HZ / 5) /* * below this threshold, we consider thinktime immediate @@ -1362,6 +1366,14 @@ cfq_group_service_tree_add(struct cfq_rb_root *st, struct cfq_group *cfqg) cfqg->vfraction = max_t(unsigned, vfr, 1); } +static inline u64 cfq_get_cfqg_vdisktime_delay(struct cfq_data *cfqd) +{ + if (!iops_mode(cfqd)) + return CFQ_SLICE_MODE_GROUP_DELAY; + else + return CFQ_IOPS_MODE_GROUP_DELAY; +} + static void cfq_group_notify_queue_add(struct cfq_data *cfqd, struct cfq_group *cfqg) { @@ -1381,7 +1393,8 @@ cfq_group_notify_queue_add(struct cfq_data *cfqd, struct cfq_group *cfqg) n = rb_last(&st->rb); if (n) { __cfqg = rb_entry_cfqg(n); - cfqg->vdisktime = __cfqg->vdisktime + CFQ_IDLE_DELAY; + cfqg->vdisktime = __cfqg->vdisktime + + cfq_get_cfqg_vdisktime_delay(cfqd); } else cfqg->vdisktime = st->min_vdisktime; cfq_group_service_tree_add(st, cfqg);