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

[hanjinke]

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