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 -- 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
