3 ms·
Regarding why block io limiting isn't implemented yet in Kube - its really hard to make block io sharing work well without killing performance (it's easy for on
by smarterclayton 9y ago
Regarding why block io limiting isn't implemented yet in Kube - its really hard to make block io sharing work well without killing performance (it's easy for one workload to screw up another if it seeks at the wrong time, and ssds are fast enough that just having to check the io limits may severely limit your max throughout). If you read some of the proposals for io, the end goal is to make it easy to use multiple volumes per workload where possible, and have high level limits in place for other things like inodes, total writes, etc.
- skyde 9y agoIsn't that what BFQ scheduler was designed for ?
- smarterclayton 9y agoYes, although even the 4.12 code can have substantial overhead vs NOOP (phoronix benchmarks, as an example). It's not a complete slam dunk - turning it on for io indifferent workloads might make sense, but not necessarily on all boxes. http://www.phoronix.com/scan.php?page=article&item=linux-412-io&num=2 http://www.phoronix.com/scan.php?page=article&item=linux-412...
- AstralStorm 9y agoPhoronix tested BFQ in low latency mode on throughput. Results are obvious. There is a simple twiddle for that. Of course they didn't test fairness or latency, that is too hard.
- smarterclayton 9y agoYeah, I'd love to see comprehensive benchmarks of competing workloads on larger scale boxes. If workload isolation can be achieved with moderately low overhead (15%?), there would be a lot of interest in pushing a default setup with BFQ in Kubernetes once more stable kernel streams have it available.
- gtirloni 9y agoThanks for the background information. Would you have a link for those proposals?
- smarterclayton 9y agohttps://github.com/kubernetes/community/pull/306 https://github.com/kubernetes/community/pull/306 Has both the discussion and the current proposed path for io separation.