Message ID | 20221123060401.20392-6-shikemeng@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2614571wrr; Tue, 22 Nov 2022 22:05:11 -0800 (PST) X-Google-Smtp-Source: AA0mqf4mSPOp6tJ7/qYn6CW+2L00Lo5m+yFBRLp2y9qnMZAv3IXLfuYoliICnzNmr6jNby2oje0O X-Received: by 2002:a17:903:1314:b0:186:9b19:1dbb with SMTP id iy20-20020a170903131400b001869b191dbbmr18655691plb.59.1669183510799; Tue, 22 Nov 2022 22:05:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669183510; cv=none; d=google.com; s=arc-20160816; b=GGlmiAg6BJYCyS0JrBjH/3AwQh74C51Zf4vqNnXzXMbl+zXCWBiMa3kcDtmeqfN4o2 e/nuzHHKvik39e15WyX1G5tIOmBo6XrUlkHuiikwmMfhX2XuO/GDsvyM/ipckSGQpp/u 4LzDISfE1suMzbriIItPra+f+qLH3CJ4M/wcm71En1g8PUFg8b53N6IP3RchWexWpM7Z FOgrdB5HFvj2UL0pyclpHlwWUmGPQJa6L2Tqe+P8U50xitQcmGQznqA75Y/JaXkjc2Zq 0S8GCqIeGIEcPB12jnZWLumi1Oi8XsCeGmEUTMznD2dCb/F7TNxRav0gVa43U8FxSPHn ruwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=unf+8vEd0DuM8K5XbysTkw1WQY21NqzNwh8U1+3iEno=; b=lQnAufTKCzR4yzBFJqMJhDZGLvCQLbE6BhH2hBBbooL8fmaQMOSgFPWq1X8HHX253b 2JpPpcvAqsHpaDVOjSloB909dDK/iVGX+B+Tkr4wbDUaiQZhlC88tKwfNe+pSpOQ7qOv FjZDgzkceMkwgwkkYGmIbBwf0LjB3d9pVum/Tgig2CMQMeaxFgbGddFg4gBY1e+bDJlN xeTcMqxxqXvBBQQ4Ae3xhbOF5vRtfxGuBC0E9DKSwP6r9AHwnXw2UghZx8+OEq+ZmfGO 4l3Rc2MqWRi8W+NqVk8PIBVn+FI8eBB3aA7W0Jm5NsPyC9gdV6zfTmXRLGDo6qpVA6kM XXcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jk12-20020a170903330c00b001893740c58asi2503163plb.393.2022.11.22.22.04.56; Tue, 22 Nov 2022 22:05:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235882AbiKWGE1 (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Wed, 23 Nov 2022 01:04:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235606AbiKWGEK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 23 Nov 2022 01:04:10 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42123F2C09; Tue, 22 Nov 2022 22:04:09 -0800 (PST) Received: from kwepemi500016.china.huawei.com (unknown [172.30.72.56]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4NH9Tv4b8SzJnrS; Wed, 23 Nov 2022 14:00:51 +0800 (CST) Received: from huawei.com (10.174.178.129) by kwepemi500016.china.huawei.com (7.221.188.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 23 Nov 2022 14:04:06 +0800 From: Kemeng Shi <shikemeng@huawei.com> To: <tj@kernel.org>, <josef@toxicpanda.com>, <axboe@kernel.dk> CC: <cgroups@vger.kernel.org>, <linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <shikemeng@huawei.com> Subject: [PATCH 05/11] blk-throttle: simpfy low limit reached check in throtl_tg_can_upgrade Date: Wed, 23 Nov 2022 14:03:55 +0800 Message-ID: <20221123060401.20392-6-shikemeng@huawei.com> X-Mailer: git-send-email 2.14.1.windows.1 In-Reply-To: <20221123060401.20392-1-shikemeng@huawei.com> References: <20221123060401.20392-1-shikemeng@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.174.178.129] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemi500016.china.huawei.com (7.221.188.220) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750265768815393681?= X-GMAIL-MSGID: =?utf-8?q?1750265768815393681?= |
Series |
A few bugfix and cleanup patches for blk-throttle
|
|
Commit Message
Kemeng Shi
Nov. 23, 2022, 6:03 a.m. UTC
Cgroup reaches low limit if limit is zero or io is already queued. Cgroup
will pass upgrade check if low limits of READ and WRITE are both reached.
Simpfy the check code described above to removce repeat check and improve
readability. There is no functional change.
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
---
block/blk-throttle.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
Comments
On Wed, Nov 23, 2022 at 02:03:55PM +0800, Kemeng Shi wrote: > -static bool throtl_tg_can_upgrade(struct throtl_grp *tg) > +static bool throtl_tg_reach_low_limit(struct throtl_grp *tg, int rw) > { > struct throtl_service_queue *sq = &tg->service_queue; > - bool read_limit, write_limit; > + bool limit = tg->bps[rw][LIMIT_LOW] || tg->iops[rw][LIMIT_LOW]; > > /* > * if cgroup reaches low limit (if low limit is 0, the cgroup always > * reaches), it's ok to upgrade to next limit > */ > - read_limit = tg->bps[READ][LIMIT_LOW] || tg->iops[READ][LIMIT_LOW]; > - write_limit = tg->bps[WRITE][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW]; > - if (!read_limit && !write_limit) > - return true; > - if (read_limit && sq->nr_queued[READ] && > - (!write_limit || sq->nr_queued[WRITE])) > - return true; > - if (write_limit && sq->nr_queued[WRITE] && > - (!read_limit || sq->nr_queued[READ])) > + return !limit || sq->nr_queued[rw]. > +} > + > +static bool throtl_tg_can_upgrade(struct throtl_grp *tg) > +{ > + if (throtl_tg_reach_low_limit(tg, READ) && > + throtl_tg_reach_low_limit(tg, WRITE)) Are the conditions being checked actually equivalent? If so, can you explicitly explain that these are equivalent conditions? If not, what are we changing exactly? Thanks.
on 11/24/2022 2:26 AM, Tejun Heo wrote: > On Wed, Nov 23, 2022 at 02:03:55PM +0800, Kemeng Shi wrote: >> -static bool throtl_tg_can_upgrade(struct throtl_grp *tg) >> +static bool throtl_tg_reach_low_limit(struct throtl_grp *tg, int rw) >> { >> struct throtl_service_queue *sq = &tg->service_queue; >> - bool read_limit, write_limit; >> + bool limit = tg->bps[rw][LIMIT_LOW] || tg->iops[rw][LIMIT_LOW]; >> >> /* >> * if cgroup reaches low limit (if low limit is 0, the cgroup always >> * reaches), it's ok to upgrade to next limit >> */ >> - read_limit = tg->bps[READ][LIMIT_LOW] || tg->iops[READ][LIMIT_LOW]; >> - write_limit = tg->bps[WRITE][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW]; >> - if (!read_limit && !write_limit) >> - return true; >> - if (read_limit && sq->nr_queued[READ] && >> - (!write_limit || sq->nr_queued[WRITE])) >> - return true; >> - if (write_limit && sq->nr_queued[WRITE] && >> - (!read_limit || sq->nr_queued[READ])) >> + return !limit || sq->nr_queued[rw]. >> +} >> + >> +static bool throtl_tg_can_upgrade(struct throtl_grp *tg) >> +{ >> + if (throtl_tg_reach_low_limit(tg, READ) && >> + throtl_tg_reach_low_limit(tg, WRITE)) > > Are the conditions being checked actually equivalent? If so, can you > explicitly explain that these are equivalent conditions? If not, what are we > changing exactly?All replaced conditions to return true are as following: condition 1 (!read_limit && !write_limit) condition 2 read_limit && sq->nr_queued[READ] && (!write_limit || sq->nr_queued[WRITE]) condition 3 write_limit && sq->nr_queued[WRITE] && (!read_limit || sq->nr_queued[READ]) Transfering condition 2 as following: read_limit && sq->nr_queued[READ] && (!write_limit || sq->nr_queued[WRITE]) is equivalent to (read_limit && sq->nr_queued[READ]) && (!write_limit || (write_limit && sq->nr_queued[WRITE])) is equivalent to (read_limit && sq->nr_queued[READ] && !write_limit) || ((read_limit && sq->nr_queued[READ] && (write_limit && sq->nr_queued[WRITE])) Transfering condition 3 as following: write_limit && sq->nr_queued[WRITE] && (!read_limit || sq->nr_queued[READ]) is equivalent to (write_limit && sq->nr_queued[WRITE]) && (!read_limit || (read_limit && sq->nr_queued[READ])) is equivalent to ((write_limit && sq->nr_queued[WRITE]) && !read_limit) || ((write_limit && sq->nr_queued[WRITE]) && (read_limit && sq->nr_queued[READ])) All replaced conditions to return true are collected as folloing: condition 1.1 (!read_limit && !write_limit) condition 1.2 (read_limit && sq->nr_queued[READ] && !write_limit) condition 1.3 ((read_limit && sq->nr_queued[READ] && (write_limit && sq->nr_queued[WRITE])) condition 1.4 (write_limit && sq->nr_queued[WRITE]) && !read_limit) condition 1.5 (the same as 1.3, can be ingored) (write_limit && sq->nr_queued[WRITE]) && (read_limit && sq->nr_queued[READ])) Condtions to return true in this patch is: (!read_limit || (read_limit && sq->nr_queued[READ])) && (!write_limit || (write_limit && sq->nr_queued[WRITE])) As "(a || b) && (c || d)" can be extracted to (a && c) or (a && d) or (b && c) or (b && d ). So we can extract condtions to condition 2.1 !read_limit && !write_limit condition 2.2 !read_limit && (write_limit && sq->nr_queued[WRITE]) condition 2.3 (read_limit && sq->nr_queued[READ]) && !write_limit condition 2.4 (read_limit && sq->nr_queued[READ]) && (write_limit && sq->nr_queued[WRITE]) Conditions match as following: condition 1.1 = condition 2.1 condition 1.2 = condition 2.3 condition 1.3 = condition 2.4 condition 1.4 = condition 2.2
Hi Kemeng, Thank you for the patch! Yet something to improve: [auto build test ERROR on axboe-block/for-next] [also build test ERROR on linus/master v6.1-rc6 next-20221125] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Kemeng-Shi/A-few-bugfix-and-cleanup-patches-for-blk-throttle/20221123-140704 base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next patch link: https://lore.kernel.org/r/20221123060401.20392-6-shikemeng%40huawei.com patch subject: [PATCH 05/11] blk-throttle: simpfy low limit reached check in throtl_tg_can_upgrade config: x86_64-randconfig-a005 compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/79d5eb2da90b359d735d434c745a5d6f9c1a690c git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Kemeng-Shi/A-few-bugfix-and-cleanup-patches-for-blk-throttle/20221123-140704 git checkout 79d5eb2da90b359d735d434c745a5d6f9c1a690c # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): >> block/blk-throttle.c:1813:1: error: expected identifier } ^ 1 error generated. vim +1813 block/blk-throttle.c 1802 1803 static bool throtl_tg_reach_low_limit(struct throtl_grp *tg, int rw) 1804 { 1805 struct throtl_service_queue *sq = &tg->service_queue; 1806 bool limit = tg->bps[rw][LIMIT_LOW] || tg->iops[rw][LIMIT_LOW]; 1807 1808 /* 1809 * if cgroup reaches low limit (if low limit is 0, the cgroup always 1810 * reaches), it's ok to upgrade to next limit 1811 */ 1812 return !limit || sq->nr_queued[rw]. > 1813 } 1814
diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 01e30380c19b..322a6ee38fb6 100644 --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -1800,24 +1800,22 @@ static bool throtl_tg_is_idle(struct throtl_grp *tg) return ret; } -static bool throtl_tg_can_upgrade(struct throtl_grp *tg) +static bool throtl_tg_reach_low_limit(struct throtl_grp *tg, int rw) { struct throtl_service_queue *sq = &tg->service_queue; - bool read_limit, write_limit; + bool limit = tg->bps[rw][LIMIT_LOW] || tg->iops[rw][LIMIT_LOW]; /* * if cgroup reaches low limit (if low limit is 0, the cgroup always * reaches), it's ok to upgrade to next limit */ - read_limit = tg->bps[READ][LIMIT_LOW] || tg->iops[READ][LIMIT_LOW]; - write_limit = tg->bps[WRITE][LIMIT_LOW] || tg->iops[WRITE][LIMIT_LOW]; - if (!read_limit && !write_limit) - return true; - if (read_limit && sq->nr_queued[READ] && - (!write_limit || sq->nr_queued[WRITE])) - return true; - if (write_limit && sq->nr_queued[WRITE] && - (!read_limit || sq->nr_queued[READ])) + return !limit || sq->nr_queued[rw]. +} + +static bool throtl_tg_can_upgrade(struct throtl_grp *tg) +{ + if (throtl_tg_reach_low_limit(tg, READ) && + throtl_tg_reach_low_limit(tg, WRITE)) return true; if (time_after_eq(jiffies,