lkml.org 
[lkml]   [2023]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [External] Re: [PATCH v3] blk-throtl: Introduce sync and async queues for blk-throtl
From


在 2023/1/10 上午2:08, Tejun Heo 写道:
> Hello,
>
> On Sat, Jan 07, 2023 at 12:44:35PM +0800, hanjinke wrote:
>> 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.
>
> Ah, I see. Do you use the latency targets and min/max ranges or just fixate
> the vrate by setting min == max?

Currently we use the former.

>
>> 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.
>
> Glad to hear.
>
>> These practices can be done better and I look forward to your better
>> suggestions.
>
> It's still in progress but resctl-bench's iocost-tune benchmark is what
> we're starting to use:
>
> https://github.com/facebookexperimental/resctl-demo/blob/main/resctl-bench/doc/iocost-tune.md
>
> The benchmark takes like 6 hours and what it does is probing the whole vrate
> range looking for behavior inflection points given the scenario of
> protecting a latency sensitive workload against memory leak. On completion,
> it provides several solutions based on the behavior observed.
>
> The benchmark is destructive (to the content on the target ssd) and can be
> tricky to set up. There's installable image to help setting up and running
> the benchmark:
>
> https://github.com/iocost-benchmark/resctl-demo-image-recipe/actions
>
> The eventual goal is collecting these benchmark results in the following git
> repo:
>
> https://github.com/iocost-benchmark/iocost-benchmarks
>
> which generates hwdb files describing all the found solution and make
> systemd apply the appropriate configuration on boot automatically.
>
> It's still all a work in progress but hopefully we should be able to
> configure iocost reasonably on boot on most SSDs.
>
> Thanks.
>

These methodologies are worthy of our study and will definitely help our
future deployment of iocost. Thanks a lot.

Thanks.

\
 
 \ /
  Last update: 2023-03-26 23:34    [W:0.075 / U:2.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site