IO less throttling and cgroup aware writeback (Was: Re: [Lsf] Preliminary Agenda and Activities for LSF)

[Vivek Goyal <vgoyal@redhat.com>]

On Wed, Mar 30, 2011 at 03:18:02PM +1100, Dave Chinner wrote:
> On Tue, Mar 29, 2011 at 10:35:13AM -0700, Chad Talbott wrote:
> > I'd like to propose a discussion topic:
> > 
> > IO-less Dirty Throttling Considered Harmful...
> > 
> > to isolation and cgroup IO schedulers in general.
> 
> Why is that, exactly? The current writeback infrastructure isn't
> cgroup aware at all, so isn't that the problem you need to solve
> first?  i.e. how to delegate page cache writeback from
> one context to anotheri and account for it correctly?
> 
> Once you solve that problem, triggering cgroup specific writeback
> from the throttling code is the same regardless of whether we
> are doing IO directly from the throttling code or via a separate
> flusher thread. Hence I don't really understand why you think
> IO-less throttling is really a problem.

Dave,

We are planning to track the IO context of original submitter of IO
by storing that information in page_cgroup. So that is not the problem.

The problem google guys are trying to raise is that can a single flusher
thread keep all the groups on bdi busy in such a way so that higher
prio group can get more IO done. It should not happen that flusher
thread gets blocked somewhere (trying to get request descriptors on
request queue) or it tries to dispatch too much IO from an inode which
primarily contains pages from low prio cgroup and high prio cgroup
task does not get enough pages dispatched to device hence not getting
any prio over low prio group.

Currently we can do some IO in the context of writting process also
hence faster group can try to dispatch its own pages to bdi for writeout.
With IO less throttling, that notion will disappear.

So the concern they raised that is single flusher thread per device
is enough to keep faster cgroup full at the bdi and hence get the
service differentiation.

My take on this is that on slow SATA device it might be as long as
we make sure that flusher thread does not block on individual groups
and also try to select inodes intelligently (cgroup aware manner).

If it really becomes an issue on faster devices, will a flusher thread
per cgroup per bdi make sense.

Thanks
Vivek