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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
