On Tue, 14 Apr 2009 22:21:11 +0200 Andrea Righi <righi.andrea@xxxxxxxxx> wrote: > Objective > ~~~~~~~~~ > The objective of the io-throttle controller is to improve IO performance > predictability of different cgroups that share the same block devices. We should get an IO controller into Linux. Does anyone have a reason why it shouldn't be this one? > Respect to other priority/weight-based solutions the approach used by > this controller is to explicitly choke applications' requests Yes, blocking the offending application at a high level has always seemed to me to be the best way of implementing the controller. > that > directly or indirectly generate IO activity in the system (this > controller addresses both synchronous IO and writeback/buffered IO). The problem I've seen with some of the proposed controllers was that they didn't handle delayed writeback very well, if at all. Can you explain at a high level but in some detail how this works? If an application is doing a huge write(), how is that detected and how is the application made to throttle? Does it add new metadata to `struct page' for this? I assume that the write throttling is also wired up into the MAP_SHARED write-fault path? Does this patchset provide a path by which we can implement IO control for (say) NFS mounts? _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
