Re: [LSF/MM TOPIC] [ATTEND] Throttling I/O

[Tejun Heo <tj@kernel.org>]

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