From: Kemeng Shi <shikemeng@huawei.com>
To: Tejun Heo <tj@kernel.org>
Cc: <josef@toxicpanda.com>, <axboe@kernel.dk>,
<cgroups@vger.kernel.org>, <linux-block@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/11] blk-throttle: simpfy low limit reached check in throtl_tg_can_upgrade
Date: Thu, 24 Nov 2022 20:52:50 +0800 [thread overview]
Message-ID: <64e54286-2c77-7162-4d50-1c644d1f0caf@huawei.com> (raw)
In-Reply-To: <Y35l3cRfYNgCzBgC@slm.duckdns.org>
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
--
Best wishes
Kemeng Shi
next prev parent reply other threads:[~2022-11-24 12:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 6:03 [PATCH 00/11] A few bugfix and cleanup patches for blk-throttle Kemeng Shi
2022-11-23 6:03 ` [PATCH 01/11] blk-throttle: Limit whole system if root group is configured when on the default hierarchy Kemeng Shi
2022-11-23 17:11 ` Tejun Heo
2022-11-24 11:47 ` Kemeng Shi
2022-11-23 6:03 ` [PATCH 02/11] blk-throttle: Fix that bps of child could exceed bps limited in parent Kemeng Shi
2022-11-23 18:09 ` Tejun Heo
2022-11-24 11:49 ` Kemeng Shi
2022-11-23 6:03 ` [PATCH 03/11] blk-throttle: ignore cgroup without io queued in blk_throtl_cancel_bios Kemeng Shi
2022-11-23 18:13 ` Tejun Heo
2022-11-23 6:03 ` [PATCH 04/11] blk-throttle: correct calculation of wait time in tg_may_dispatch Kemeng Shi
2022-11-23 18:18 ` Tejun Heo
2022-11-24 12:10 ` Kemeng Shi
2022-11-23 6:03 ` [PATCH 05/11] blk-throttle: simpfy low limit reached check in throtl_tg_can_upgrade Kemeng Shi
2022-11-23 18:26 ` Tejun Heo
2022-11-24 12:52 ` Kemeng Shi [this message]
2022-11-26 5:03 ` kernel test robot
2022-11-23 6:03 ` [PATCH 06/11] blk-throttle: fix typo in comment of throtl_adjusted_limit Kemeng Shi
2022-11-23 18:26 ` Tejun Heo
2022-11-23 6:03 ` [PATCH 07/11] blk-throttle: remove incorrect comment for tg_last_low_overflow_time Kemeng Shi
2022-11-23 18:27 ` Tejun Heo
2022-11-23 6:03 ` [PATCH 08/11] blk-throttle: remove repeat check of elapsed time from last upgrade in throtl_hierarchy_can_downgrade Kemeng Shi
2022-11-23 18:28 ` Tejun Heo
2022-11-24 12:58 ` Kemeng Shi
2022-11-26 8:15 ` kernel test robot
2022-11-23 6:03 ` [PATCH 09/11] blk-throttle: remove unnecessary check for validation of limit index Kemeng Shi
2022-11-23 18:31 ` Tejun Heo
2022-11-24 12:58 ` Kemeng Shi
2022-11-23 6:04 ` [PATCH 10/11] blk-throttle: remove unused variable td in tg_update_has_rules Kemeng Shi
2022-11-23 18:30 ` Tejun Heo
2022-11-23 6:04 ` [PATCH 11/11] blk-throttle: Use more siutable time_after check for update slice_start Kemeng Shi
2022-11-23 18:29 ` Tejun Heo
2022-11-24 13:02 ` Kemeng Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64e54286-2c77-7162-4d50-1c644d1f0caf@huawei.com \
--to=shikemeng@huawei.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®