# Re: question about relative control for sync io using bfq

- From: yukuai (C) \<hidden\>
- Date: 2021-02-07 12:50:05 
- List: linux-block
- Page: https://ratatoskr.run/linux-block/2021/02/6400868
- Thread: https://ratatoskr.run/linux-block/2021/02/6400832/t.md

```text

On 2021/02/05 15:49, Paolo Valente wrote:
>
>
>> Il giorno 29 gen 2021, alle ore 09:28, yukuai (C) [ref] ha scritto:
>>
>> Hi,
>>
>> Thanks for your response, and my apologize for the delay, my tmie
>> is very limited recently.
>>
>
> I do know that problem ...
>
>> On 2021/01/22 18:09, Paolo Valente wrote:
>>> Hi,
>>> this is a core problem, not of BFQ but of any possible solution that
>>> has to provide bandwidth isolation with sync I/O.  One of the examples
>>
>> I'm not sure about this, so I test it with iocost in mq and cfq in sq,
>> result shows that they do can provide bandwidth isolation with sync I/O
>> without significant performance degradation.
>
> Yep, that means just that, with your specific workload, bandwidth
> isolation gets guaranteed without idling.  So that's exactly one of
> the workloads for which I'm suggesting my handling of a special case.
>
>
>>> is the one I made for you in my other email.  At any rate, the problem
>>> that you report seems to occur with just one group.  We may think of
>>> simply changing my condition
>>> bfqd->num_groups_with_pending_reqs > 0
>>> to
>>> bfqd->num_groups_with_pending_reqs > 1
>>
>> We aredy tried this, the problem will dispeare if only one group is
>> active. And I think this modification is reasonable because
>> bandwidth isolation is not necessary in this case.
>>
>
> Thanks for your feedback. I'll consider submitting this change.
>
>> However, considering the common case, when more than one
>> group is active, and one of the group is issuing sync IO, I think
>> we need to find a way to prevent the preformance degradation.
>
> I agree.  What do you think of my suggestion for solving the problem?
> Might you help with that?

Hi

Do you mead the suggestion that you mentioned in another email:
"a varied_rq_size flag, similar to the varied_weights flag" ?
I'm afraid that's just a circumvention plan, not a solution to the
special case.

By the way, I'm glad if there is anything I can help, however it'll
wait for a few days cause the Spring Festival is coming.

Thanks,
Yu Kuai

>
> Thanks,
> Paolo
>
>>> If this simple solution does solve the problem you report, then I
>>> could run my batch of tests to check whether it causes some
>>> regression.
>>> What do you think?
>>> Thanks.
>>> Paolo
>>
>> Thanks
>> Yu Kuai
>>> .
>
> .
>
```