Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device
From: Tejun Heo
Date: Wed Jun 05 2013 - 13:36:25 EST
On Wed, Jun 05, 2013 at 09:55:12AM -0400, Vivek Goyal wrote:
> I think it will be hard to cover all the use cases. There is a reason
> why CFQ got so complicated and bulky because it tried to cover all the
> use cases and provide service differentiation among workloads. blk-cgroup
> will try to do the same thing at group level. All these question will
> arise when to idle, how much to idle, how much device queue depth we
> should drive to keep service differention better, how much outstanding
> IO from each group we should allow in the queue.
Yes but that's because we were trying to serve disks with rotating
platters. I don't think we can use the same thing for disks and
non-rotational devices. For the latter, things get a lot simpler.
Note that even the current blk-throttle doesn't care about the
underlying device at all. We can do the same thing for proportional
control in a hopefully better and scalable way of course.
> And all of this affects what kind of service differentation you see
> on different devices for different workloads.
> I think generic implementation can be written with the goal of trying to
> make it work with faster flash devices (which will typically use blk-mq).
> And for slower disks, one can continue to use CFQ's cgroup implementation.
Yeap. Pretty much the same feeling here.
> On a side note, it would be nice if we handle problem of managing buffered
> writes using cgroup first. Otherwise there are very few practical
> scenarios where proportional IO thing can be used.
Indeed. It's currently below unified hierarchy in my todo list but if
you wanna tackle it, I'll be happy to help.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/