--- /dev/null
+<!DOCTYPE html>
+<html>
+<head>
+ <meta http-equiv='content-type' content='text/html; charset=utf-8'>
+ <meta name='viewport' content='width=device-width, initial-scale=1.0'>
+ <style type='text/css'>
+ body { margin: 1em 15%; }
+ </style>
+</head>
+<body>
+<div class='story-header'>
+ <h1><a href='0000763603.html'>[$] Measuring (and fixing) I/O-controller throughput loss</a></h1>
+ <div class='details'>([Kernel] Aug 29, 2018 21:20 UTC (Wed) (corbet))</div>
+ <br/>
+ <div class='content' style='text-align: justify'>
+ Many services, from web hosting and video streaming to cloud storage, need to move data to and from storage. They also often require that each per-client I/O flow be guaranteed a non-zero amount of bandwidth and a bounded latency. An expensive way to provide these guarantees is to over-provision storage resources, keeping each resource underutilized, and thus have plenty of bandwidth available for the few I/O flows dispatched to each medium. Alternatively one can use an I/O controller. Linux provides two mechanisms designed to throttle some I/O streams to allow others to meet their bandwidth and latency requirements. These mechanisms work, but they come at a cost: a loss of as much as 80% of total available I/O bandwidth. I have run some tests to demonstrate this problem; some upcoming improvements to the bfq I/O scheduler promise to improve the situation considerably.
+ </div>
+<hr/>
+</div>
+</body>
git://git.nikiroo.be / gofetch.git / blobdiff