3 ms·

Sorry, I don't understand what this article is taking about. Is it about the classical CFQ/Deadline I/O schedulers and/or the new multiqueue schedulers? Or some

Sorry, I don't understand what this article is taking about. Is it about the classical CFQ/Deadline I/O schedulers and/or the new multiqueue schedulers? Or something completely different? Thx :)

viraptor 8y ago
The way I understand it is it's a new thing, stacked with the selectable io schedulers. But it can reach deeper than them - specifically when you're writing dirty pages back to the disk in the background the existing schedulers were not aware of how to manage that. This one does. (please correct me if I got something wrong)
- zepearl 8y ago
  > specifically when you're writing dirty pages back to the disk in the background Mmmmhh, it this is true then it would affect the order of how the "writeback buffers" are written to disk? If yes then I guess that this can potentially be dangerous (no assumption anymore of "1st come 1st served?")?
  - viraptor 8y ago
    From the description it looks like it only throttles the new submissions while the writeback catches up.
    - zepearl 8y ago
      Thx
ignoramous 8y ago
(per my understanding) This isn't about a new io-scheduler. You'd use this io.latency io-controller that sits a layer above the io-scheduler and reduces io queue-size as a means to throttle write requests. The key insight in how to do this per control-group is to use a hierarchical non-blocking data-structure to represent related workloads, which could be classified into 'fast' and 'slow', with 'fast' penalising the 'slow' group (by the way of reducing the io queue-size available to it) iff 'fast' sees higher read latencies. 'Unrelated' group doesn't get penalised as it isn't part of the same hierarchy, as it were. There are some gotchas though, for instance, priority inversion occurs where 'fast' needs more memory but 'slow' needs to be paged-out first, resulting in 'fast' being peanlized indirectly for the write-throttling on 'slow'. The approach here is reminiscent of HFSC qdisc for TCP/IP (which only a handful of people understand?): https://www.cs.cmu.edu/~hzhang/HFSC/main.html https://www.cs.cmu.edu/~hzhang/HFSC/main.html
- zepearl 8y ago
  Thx

Sorry, I don't understand what this article is taking about. Is it about the classical CFQ/Deadline I/O schedulers and/or the new multiqueue schedulers? Or something completely different? Thx :)

viraptor 8y ago

The way I understand it is it's a new thing, stacked with the selectable io schedulers. But it can reach deeper than them - specifically when you're writing dirty pages back to the disk in the background the existing schedulers were not aware of how to manage that. This one does. (please correct me if I got something wrong)

zepearl 8y ago
> specifically when you're writing dirty pages back to the disk in the background Mmmmhh, it this is true then it would affect the order of how the "writeback buffers" are written to disk? If yes then I guess that this can potentially be dangerous (no assumption anymore of "1st come 1st served?")?
- viraptor 8y ago
  From the description it looks like it only throttles the new submissions while the writeback catches up.
  - zepearl 8y ago
    Thx

ignoramous 8y ago

(per my understanding) This isn't about a new io-scheduler. You'd use this io.latency io-controller that sits a layer above the io-scheduler and reduces io queue-size as a means to throttle write requests. The key insight in how to do this per control-group is to use a hierarchical non-blocking data-structure to represent related workloads, which could be classified into 'fast' and 'slow', with 'fast' penalising the 'slow' group (by the way of reducing the io queue-size available to it) iff 'fast' sees higher read latencies. 'Unrelated' group doesn't get penalised as it isn't part of the same hierarchy, as it were. There are some gotchas though, for instance, priority inversion occurs where 'fast' needs more memory but 'slow' needs to be paged-out first, resulting in 'fast' being peanlized indirectly for the write-throttling on 'slow'. The approach here is reminiscent of HFSC qdisc for TCP/IP (which only a handful of people understand?): https://www.cs.cmu.edu/~hzhang/HFSC/main.html https://www.cs.cmu.edu/~hzhang/HFSC/main.html

zepearl 8y ago
Thx