> Il giorno 04 ott 2016, alle ore 21:14, Tejun Heo <tj@xxxxxxxxxx> ha scritto: > > Hello, Paolo. > > On Tue, Oct 04, 2016 at 09:02:47PM +0200, Paolo Valente wrote: >> That's exactly what BFQ has succeeded in doing in all the tests >> devised so far. Can you give me a concrete example for which I can >> try with BFQ and with any other mechanism you deem better. If >> you are right, numbers will just make your point. > > Hmm... I think we already discussed this but here's a really simple > case. There are three unknown workloads A, B and C and we want to > give A certain best-effort guarantees (let's say around 80% of the > underlying device) whether A is sharing the device with B or C. > That's the same example that you proposed me in our previous discussion. For this example I showed you, with many boring numbers, that with BFQ you get the most accurate distribution of the resource. If you have enough stamina, I can repeat them again. To save your patience, here is a very brief summary. In a concrete use case, the unknown workloads turn into something like this: there will be a first time interval during which A happens to be, say, sequential, B happens to be, say, random and C happens to be, say, quasi-sequential. Then there will be a next time interval during which their characteristics change, and so on. It is easy (but boring, I acknowledge it) to show that, for each of these time intervals BFQ provides the best possible service in terms of fairness, bandwidth distribution, stability and so on. Why? Because of the elastic bandwidth-time scheduling of BFQ that we already discussed, and because BFQ is naturally accurate in redistributing aggregate throughput proportionally, when needed. > I get that bfq can be a good compromise on most desktop workloads and > behave reasonably well for some server workloads with the slice > expiration mechanism but it really isn't an IO resource partitioning > mechanism. > Right. My argument is that BFQ enables you to give to each client the bandwidth and low-latency guarantees you want. And this IMO is way better than partitioning a resource and then getting unavoidable unfairness and high latency. Thanks, Paolo > Thanks. > > -- > tejun -- Paolo Valente Algogroup Dipartimento di Scienze Fisiche, Informatiche e Matematiche Via Campi 213/B 41125 Modena - Italy http://algogroup.unimore.it/people/paolo/ -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
