Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device

[Tejun Heo]

Hello, Vivek.

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.

Thanks.

-- 
tejun
--
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/