Re: [External] Re: [PATCH v3] blk-throtl: Introduce sync and async queues for blk-throtl

[hanjinke <hanjinke.666@bytedance.com>]

在 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.