On Thu, Mar 17, 2011 at 03:46:41PM +0100, Jan Kara wrote: [..] > > - bdi writeback: will revert some of the mmotm memcg dirty limit changes to > > fs-writeback.c so that wb_do_writeback() will return to checking > > wb_check_background_flush() to check background limits and being > > interruptible if > > sync flush occurs. wb_check_background_flush() will check the global > > memcg_over_bg_limit list for memcg that are over their dirty limit. > > wb_writeback() will either (I am not sure): > > a) scan memcg's bdi_memcg list of inodes (only some of them are dirty) > > b) scan bdi dirty inode list (only some of them in memcg) using > > inode_in_memcg() to identify inodes to write. inode_in_memcg(inode,memcg), > > would walk memcg- -> memcg_bdi -> memcg_mapping to determine if the memcg > > is caching pages from the inode. > Hmm, both has its problems. With a) we could queue all the dirty inodes > from the memcg for writeback but then we'd essentially write all dirty data > for a memcg, not only enough data to get below bg limit. And if we started > skipping inodes when memcg(s) inode belongs to get below bg limit, we'd > risk copying inodes there and back without reason, cases where some inodes > never get written because they always end up skipped etc. Also the question > whether some of the memcgs inode belongs to is still over limit is the > hardest part of solution b) so we wouldn't help ourselves much. May be I am missing something but can't we just start traversing through list of memcg_over_bg_list and take option a) to traverse through list of inodes and write them till we are below limit of that group. We of course skip inodes which are not dirty. This is assuming that root group is also part of that list so that inodes in root group do not starve writeback. We still continue to have all the inodes on bdi wb structure and memcg will just give us pointers to those inodes. So for background write, instead of going serially through dirty inodes list, we will first pick the cgroup to write and then inode to write. As we will be doing round robin among cgroup list, it will make sure that none of the cgroups (including root) as well as inode are not starved. What am I missing? Thanks Vivek -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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>