The creation of the io.latency block I/O controller

At the time I was doing io.latency bfq wasn't mature enough to use. bfq is more akin to our current io.weight work, however we have found in testing that the latency induced by bfq is way more than we are willing to pay for. The io scheduler infrastructure currently only operates on requests, which means they get a request and that request is holding resources up for the entirety of its lifetime. This is why io.latency/wbt operate above the io scheduler, we can throttle all we want and not affect other workloads. Throttling at the io scheduler level means we're still holding on to that extra resource and punishing all the other workloads because of this lack of resource.

This isn't an impossible problem to solve by any means, and is not a complaint against bfq itself. We just know this method works, and it works extremely well, and then allows us to run whatever io scheduler we want underneath it, wether it's kyber or mq-deadline or whatever.