From: hanjinke <hanjinke.666@bytedance.com>
To: Tejun Heo <tj@kernel.org>
Cc: "Jan Kara" <jack@suse.cz>, "Michal Koutný" <mkoutny@suse.com>,
josef@toxicpanda.com, axboe@kernel.dk, cgroups@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
yinxin.x@bytedance.com
Subject: Re: [External] Re: [PATCH v3] blk-throtl: Introduce sync and async queues for blk-throtl
Date: Sat, 7 Jan 2023 12:44:35 +0800 [thread overview]
Message-ID: <e499f088-8ed9-2e19-b2e5-efaa4f9738f0@bytedance.com> (raw)
In-Reply-To: <Y7hlX4T1UOmQHiGf@slm.duckdns.org>
在 2023/1/7 上午2:15, Tejun Heo 写道:
> Hello,
>
> On Sat, Jan 07, 2023 at 02:07:38AM +0800, hanjinke wrote:
>> In our internal scenario, iocost has been deployed as the main io isolation
>> method and is gradually spreading。
>
> Ah, glad to hear. If you don't mind sharing, how are you configuring iocost
> currently? How do you derive the parameters?
>
For cost.model setting, We first use the tools iocost provided to test
the benchmark model parameters of different types of disks online, and
then save these benchmark parameters to a parametric Model Table. During
the deployment process, pull and set the corresponding model parameters
according to the type of disk.
The setting of cost.qos should be considered slightly more,we need to
make some compromises between overall disk throughput and io latency.
The average disk utilization of the entire disk on a specific business
and the RLA(if it is io sensitive) of key businesses will be taken as
important input considerations. The cost.qos will be dynamically
fine-tuned according to the health status monitoring of key businesses.
For cost.weight setting, high-priority services will gain greater
advantages through weight settings to deal with a large number of io
requests in a short period of time. It works fine as work-conservation
of iocost works well according to our observation.
These practices can be done better and I look forward to your better
suggestions.
> blk-throttle has a lot of issues which may be difficult to address. Even the
> way it's configured is pretty difficult to scale across different hardware /
> application combinations and we've neglected its control performance and
> behavior (like handling of shared IOs) for quite a while.
>
> While iocost's work-conserving control does address a lot of the use cases
> we see today, it's likely that we'll need hard limits more in the future
> too. I've been thinking about implementing io.max on top of iocost. There
> are some challenges around dynamic vrate adj semantics but it's kinda
> attractive because iocost already has the concept of total device capacity.
Indeed in our multi-tenancy scenario, the hard limits are necessary.
Jinke
Thanks.
next prev parent reply other threads:[~2023-01-07 4:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-26 13:05 [PATCH v3] blk-throtl: Introduce sync and async queues for blk-throtl Jinke Han
2022-12-26 15:24 ` kernel test robot
[not found] ` <20221226130505.7186-1-hanjinke.666-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>
2023-01-04 22:11 ` Tejun Heo
[not found] ` <Y7X5rsnYCAAYRGQd-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-01-05 7:28 ` [External] " hanjinke
2023-01-05 16:18 ` Michal Koutný
[not found] ` <20230105161854.GA1259-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2023-01-05 17:35 ` Tejun Heo
[not found] ` <Y7cKf7IH+FJ/6IyV-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-01-05 19:22 ` Michal Koutný
[not found] ` <20230105192247.GB16920-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2023-01-05 21:39 ` Tejun Heo
2023-01-06 15:38 ` Jan Kara
2023-01-06 16:58 ` Tejun Heo
[not found] ` <Y7hTHZQYsCX6EHIN-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-01-06 18:07 ` [External] " hanjinke
[not found] ` <c839ba6c-80ac-6d92-af64-5c0e1956ae93-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>
2023-01-06 18:15 ` Tejun Heo
2023-01-07 4:44 ` hanjinke [this message]
[not found] ` <e499f088-8ed9-2e19-b2e5-efaa4f9738f0-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>
2023-01-09 18:08 ` Tejun Heo
2023-01-10 13:07 ` hanjinke
2023-01-11 12:35 ` Michal Koutný
[not found] ` <20230111123532.GB3673-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2023-01-12 3:26 ` hanjinke
2023-01-09 10:59 ` Jan Kara
2023-01-09 17:10 ` Tejun Heo
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=e499f088-8ed9-2e19-b2e5-efaa4f9738f0@bytedance.com \
--to=hanjinke.666@bytedance.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
--cc=yinxin.x@bytedance.com \
/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