On Wed, 22 Apr 2009 09:33:49 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > > And this should be probably strictly connected to the IO controller. If > > we throttle or delay the dispatching/submission of some IO requests > > without throttling the dirty pages rate a cgroup could completely waste > > its own available memory with dirty (hard and slow to reclaim) pages. > > > > That is in part the approach I used in io-throttle v12, adding a hook in > > balance_dirty_pages_ratelimited_nr() to throttle the current task when > > cgroup's IO limit are exceeded. Argh! > > > > So, another proposal could be to re-add in io-throttle v14 the old hook > > also in balance_dirty_pages_ratelimited_nr(). > > > > In this way io-throttle would: > > > > - use page_cgroup infrastructure and page_cgroup->flags to encode the > > cgroup id that firstly dirtied a generic page > > - account and opportunely throttle sync and writeback IO requests in > > submit_bio() > > - at the same time throttle the tasks in > > balance_dirty_pages_ratelimited_nr() if the cgroup they belong has > > exhausted the IO BW (or quota, share, etc. in case of proportional BW > > limit) > > > > IMHO, io-controller should just work as I/O subsystem as bdi. Now, per-bdi dirty_ratio > is suppoted and it seems to work well. > > Can't we write a function like bdi_writeout_fraction() ?; > It will be a simple choice. > One more thing, if you want dirty_ratio for throttoling I/O not for supporing page reclaim, Something like task_dirty_limit() will be apporpriate. Thanks, -Kame _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
