Messages in this thread |  | | From | Andrea Righi <> | Subject | Re: i/o bandwidth controller infrastructure | Date | Tue, 17 Jun 2008 00:39:26 +0200 (MEST) |
| |
Divyesh Shah wrote: >> This is the core io-throttle kernel infrastructure. It creates the >> basic >> interfaces to cgroups and implements the I/O measurement and >> throttling >> functions. > > I am not sure if throttling an application's cpu usage by explicitly > putting it to sleep > in order to restrain it from making more IO requests is the way to go > here (though I can't think > of anything better right now). > With this bandwidth controller, a cpu-intensive job which otherwise > does not care about its IO > performance needs to be pin-point accurate about IO bandwidth > required in order to not suffer > from cpu-throttling. IMHO, if a cgroup is exceeding its limit for a > given resource, the throttling > should be done _only_ for that resource. > > -Divyesh
Divyesh,
I understand your point of view. It would be nice if we could just "disable" the i/o for a cgroup that exceeds its limit, instead of scheduling some sleep()s, so the tasks running in this cgroup would be able to continue their non-i/o operations as usual.
However, how to do if the tasks continue to perform i/o ops under this condition? we could just cache the i/o in memory and at the same time reduce the i/o priority of those tasks' requests, but this would require a lot of memory, more space in the page cache, and probably could lead to potential OOM conditions. A safer approach IMHO is to force the tasks to wait synchronously on each operation that directly or indirectly generates i/o. The last one is the solution implemented by this bandwidth controller.
We could collect additional statistics, or implement some heuristics to predict the tasks' i/o patterns in order to not penalize cpu-bound jobs too much, but the basic concept is the same.
Anyway, I agree there must be a better solution, but this is the best I've found right now... nice ideas are welcome.
-Andrea
|  |