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