On Tue, Jul 09, 2013 at 10:18:33AM -0400, Vivek Goyal wrote: > For implementing throttling one as such does not have to do time > slice management on the queue. For providing constructs like IOPS > or bandwidth throttling, one just need to put one throttling knob > in the cgroup pipe irrespective of time slice management on the > backing device/network. We should be providing a comprehensive mechanism to be used from userland, not something which serves pieces of specialized requirements here and there. blkio is already a mess with the capability changing depending on which elevator is in use and blk-throttle counting bios instead of merged requests making iops control a bit silly. We need to clean that up, not add more mess on top. > Also time slice management is one way of managing the backend resource. > CFQ did that and it works only for slow devices. For faster devices > we anyway need some kind of token mechanism instead of keeping track > of time. No, it is the *right* resource to manage for rotating devices if you want any sort of meaningful proportional resource distribution. It's not something one dreams up out of blue but something which arises from the fundamental operating characteristics of the device. For SSDs, iops is good enough as their latency profile is consistent enough but doing so with rotating disks doesn't yield anything useful. > So I don't think trying to manage time slice is the requirement here. For a cgroup resource controller, it *is* a frigging requirement to control the right fundamental resource at the right place where the resource resides and can be fully controlled. Nobody should have any other impression. > > and by the time you implemented proper hierarchy support and > > proportional contnrol, yours isn't gonna be that simple either. > > I suspect he is not plannnig to do any proportional control at that > layer. Just throttling mechanism. blkio should be able to do proportional control in general. The fact that we aren't able to do that except when cfq-iosched is in use is a problem which needs to be fixed. It's not a free-for-all pass for creating more broken stuff. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>