On Wed, Aug 10, 2011 at 12:41:00AM -0700, Greg Thelen wrote: [..] > > > However, before we have a "finished product", there is still another > > > piece of the puzzle to be put in place - memcg-aware buffered > > > writeback. That is, having a flusher thread do work on behalf of > > > memcg in the IO context of the memcg. Then the IO controller just > > > sees a stream of async writes in the context of the memcg the > > > buffered writes came from in the first place. The block layer > > > throttles them just like any other IO in the IO context of the > > > memcg... > > > > Yes that is still a piece remaining. I was hoping that Greg Thelen will > > be able to extend his patches to submit writes in the context of > > per cgroup flusher/worker threads and solve this problem. > > > > Thanks > > Vivek > > Are you suggesting multiple flushers per bdi (one per cgroup)? I > thought the point of IO less was to one issue buffered writes from a > single thread. I think in one of the mail threads Dave Chinner mentioned this idea of using per cgroup worker/worqueue. Agreed that it leads back to the issue of multiple writers (but only if multiple cgroups are there). But at the same time it simplifies atleast two problems. - Worker could be migrated to the cgroup we are writting for and we don't need the IO tracking logic. blkio controller should will automatically account the IO to right group. - We don't have to worry about a single flusher thread sleeping on request queue because either queue or group is congested and this can lead other group's IO is not being submitted. Thanks Vivek -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>