On Sat, Apr 16, 2011 at 09:25:46PM +0800, Wu Fengguang wrote: > Andrew, > > This revision undergoes a number of simplifications, cleanups and fixes. > Independent patches are separated out. The core patches (07, 08) now have > easier to understand changelog. Detailed rationals can be found in patch 08. > > In response to the complexity complaints, an introduction document is > written explaining the rationals, algorithm and visual case studies: > > http://www.kernel.org/pub/linux/kernel/people/wfg/writeback/slides/smooth-dirty-throttling.pdf > Hi Fenguang, I went quickly browsed through above document and am trying to understand the meaning of following lines and see how does it fit into the framework of existing IO conroller. - task IO controller endogenous - cgroup IO controller well integrated - proportional IO controller endogenous You had sent me a link where you had prepared a patch to control the async IO completely. So because this code is all about measuring the bdi writeback rate and then coming up task ratelimit accoridingly, it will never know about other IO going on in the cgroup. READS and direct IO. So IIUC, to make use of above logic for cgroup throttling, one shall have to come up with explicity notion of async bandwidth per cgroup which does not control other writes. Currently we have following when it comes to throttling. blkio.throttle_read_bps blkio.throttle_write_bps The intention is to be able to control the WRITE bandwidth of cgroup and it could be any kind of WRITE (be it buffered WRITE or direct WRITES). Currently we control only direct WRITES and question of how to also control buffered writes is still on the table. Because your patch does not know about other WRITES happening in the system, one needs to create a way so that buffered WRITES and direct WRITES can be accounted together against a group and throttled accordingly. What does "proportional IO controller endogenous" mean? Currently we do all proportional IO division in CFQ. So are you proposing that for buffered WRITES we come up with a different policy altogether in writeback layer or somehow it is integrating with CFQ mechanism? 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
