> Il giorno 7 feb 2021, alle ore 13:49, yukuai (C) <yukuai3@xxxxxxxxxx> ha scritto: > > > On 2021/02/05 15:49, Paolo Valente wrote: >>> Il giorno 29 gen 2021, alle ore 09:28, yukuai (C) <yukuai3@xxxxxxxxxx> 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. > I'm a little confused. Could you explain why you think this is a circumvention plan? Maybe even better, could you describe in detail the special case you have in mind? We could start from there, to think of a possible, satisfactory solution. > 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. > Ok, Happy Spring Festival then. Thanks. Paolo > 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 >>>> . >> .
