Re: [LSF/MM TOPIC][ATTEND]IOPS based ioscheduler
From: Shaohua Li <hidden>
Date: 2012-02-01 07:03:11
Also in:
linux-fsdevel
On Tue, 2012-01-31 at 13:12 -0500, Jeff Moyer wrote:
Shaohua Li [off-list ref] writes:quoted
Flash based storage has its characteristics. CFQ has some optimizations for it, but not enough. The big problem is CFQ doesn't drive deep queue depth, which causes poor performance in some workloads. CFQ also isn't quite fair for fast storage (or further sacrifice of performance to get fairness) because it uses time based accounting. This isn't good for block cgroup. We need something different to make both performance and fairness good. A recent attempt is to use IOPS based ioscheduler for flash based storage. It's expected to drive deep queue depth (so better performance) and be more fairness (IOPS based accounting instead of time based). I'd like to discuss: - Do we really need it? Or the question is if it is popular real workloads drive deep io depth? - Should we have a separate ioscheduler for this or merge it to CFQ? - Other implementation discussions like differentiation of read/write requests and request size. Flash based storage doesn't like rotate storage, request cost of read/write and different request size usually is different.I think you need to define a couple things to really gain traction. First, what is the target? Flash storage comes in many varieties, from really poor performance to really, really fast. Are you aiming to address all of them? If so, then let's see some numbers that prove that you're basing your scheduling decisions on the right metrics for the target storage device types.
For fast storage, like SSD or PCIe flash card.
Second, demonstrate how one workload can negatively affect another. In other words, justify the need for *any* I/O prioritization. Building on that, you'd have to show that you can't achieve your goals with existing solutions, like deadline or noop with bandwidth control.
Basically some workloads with cgroup. bandwidth control doesn't cover all requirements for cgroup users, that's why we have cgroup for CFQ anyway.
Proportional weight I/O scheduling is often sub-optimal when the device is not kept busy. How will you address that?
That's true. I choose better performance instead of better fairness if device isn't busy. Fast flash storage is expensive, I thought performance is more important in such case. Thanks, Shaohua