Hey, guys. On Fri, Jan 25, 2013 at 11:34:08AM -0500, Vivek Goyal wrote: > And I think tejun wanted to implement throttling at block layer and > wanted vm to adjust/respond to per group IO backlog when it comes > to writting to dirty data/inodes. > > Once we have take care of writeback problem then comes the issue > of being able to associate a dirty inode/page to a cgroup. Not sure > if something has happened on that front or not. In the past it was > thought to be simple that one inode belongs to one IO cgroup. Yeap, the above two sum it up pretty good. > Also seriously, in CFQ, group idling performance penalty is too > high and might start showing up easily on a single spindle sata disk > also. Especially given the fact that people will come up with hybrid > SATA drives with some caching internally. So SATA drive will not > be as slow. > > So proportional group scheduling of CFQ is limited to such a specific > corner case of slow SATA drive. I am not sure how many people really > use it. I don't think so. If you personal usages, sure, it's not very useful but then again proportional IO control itself isn't all that useful for personal use, but if you go to backend infrastructure requiring a lot of capacity, spindled drives still rule the roost and large deployment of on-device flash cache is not as immediate, if it ever happens, that is. Spindle drives may not be in your desk/laptops, but they continue to be deployed massively in the backend. For example, google has been using half-hacky hierarchical writeback support in cfq for quite some time now and they'll switch to upstream implementation once we get it working, so I don't think it's a wasted effort. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
