Paul Menage wrote: > On Mon, Aug 4, 2008 at 1:44 PM, Andrea Righi <righi.andrea@xxxxxxxxx> wrote: >> A safer approach IMHO is to force the tasks to wait synchronously on >> each operation that directly or indirectly generates i/o. >> >> In particular the solution used by the io-throttle controller to limit >> the dirty-ratio in memory is to impose a sleep via >> schedule_timeout_killable() in balance_dirty_pages() when a generic >> process exceeds the limits defined for the belonging cgroup. >> >> Limiting read operations is a lot more easy, because they're always >> synchronized with i/o requests. > > I think that you're conflating two issues: > > - controlling how much dirty memory a cgroup can have at any given > time (since dirty memory is much harder/slower to reclaim than clean > memory) > > - controlling how much effect a cgroup can have on a given I/O device. > > By controlling the rate at which a task can generate dirty pages, > you're not really limiting either of these. I think you'd have to set > your I/O limits artificially low to prevent a case of a process > writing a large data file and then doing fsync() on it, which would > then hit the disk with the entire file at once, and blow away any QoS > guarantees for other groups. > > As Dave suggested, I think it would make more sense to have your > page-dirtying throttle points hook into the memory controller instead, > and allow the memory controller to track/limit dirty pages for a > cgroup, and potentially do throttling as part of that. Yes, that would be nicer. The IO controller should control both read and write and dirty pages is mostly related to writes. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
