(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