Hello everyone, I have an idea of adding a blk-throttle tunable for cgroups to make it impose a minimum response latency for an IO by extending the blk-throttle mechanism to delay reporting to the request completion of IOs that are completed sooner than a set target. I wanted to get preliminary feedback if there are any objections against the idea and what would be possible alternatives in case this extension of blk-throttle is not suitable. I did consider using/extending dm-delay or writing a new dm-target, but that would limit applicability since the dm-layer doesn't pass-through partitions and would require alteration of a system's layout to accommodate the throttling. The motivation for the proposal is the following. I lately started experimenting with using blk-throttle mechanisms to simulate slower drives. That simulation helps understanding the sensitivity of complex heterogeneous workloads - which are infeasible to analyze analytically - to the performance of the underlying storage hardware. I found that blk-throttle is a low overhead mechanism to artificially reduce throughput (though the lack of an ability to specify a combined read+write limit is a hurdle, which I also want to address) and get somewhat representative results. But throttling BW and IOPS can not cover cases of small synchronous IOs done in critical sections - which are latency sensitive. Thus I am on a lookout for a simple mechanism to impose system wide latency throttling to simulate latency degradation without the need to alter the storage layout of the system. I believe there are more possible use cases for the mechanism, alas I can only speculate about those. Looking forward to hearing your opinion on the matter! Thanks, -- Daniil Lunev
