git://git.nikiroo.be / gofetch.git / blame
| Commit | Line | Data |
|---|---|---|
| 1aaa6ba3 NR |
1 | 0[$] Measuring (and fixing) I/O-controller throughput loss null/LWN/0000763603 70\r |
| 2 | i [Kernel] Aug 29, 2018 21:20 UTC (Wed) (corbet)\r | |
| 3 | i\r | |
| 4 | i Many services, from web hosting and video streaming to cloud\r | |
| 5 | i storage, need to move data to and from storage. They also\r | |
| 6 | i often require that each per-client I/O flow be guaranteed a\r | |
| 7 | i non-zero amount of bandwidth and a bounded latency. An\r | |
| 8 | i expensive way to provide these guarantees is to over-provision\r | |
| 9 | i storage resources, keeping each resource underutilized, and\r | |
| 10 | i thus have plenty of bandwidth available for the few I/O flows\r | |
| 11 | i dispatched to each medium. Alternatively one can use an I/O\r | |
| 12 | i controller. Linux provides two mechanisms designed to throttle\r | |
| 13 | i some I/O streams to allow others to meet their bandwidth and\r | |
| 14 | i latency requirements. These mechanisms work, but they come at\r | |
| 15 | i a cost: a loss of as much as 80% of total available I/O\r | |
| 16 | i bandwidth. I have run some tests to demonstrate this problem;\r | |
| e818d449 NR |
17 | i some upcoming improvements to the [1]bfq I/O scheduler promise\r |
| 18 | i to improve the situation considerably.\r | |
| 19 | i \r | |
| 20 | i \r | |
| 21 | i \r | |
| 22 | i [1] https://lwn.net/Articles/601799/\r | |
| 1aaa6ba3 | 23 | i\r |