On Thu, May 07, 2009 at 10:45:01AM -0400, Vivek Goyal wrote: > So now we are left with the issue of loosing the notion of priority and > class with-in cgroup. In fact on bigger systems we will probably run into > issues of kiothrottled scalability as single thread is trying to cater to > all the disks. > > If we do max bw control at IO scheduler level, then I think we should be able > to control max bw while maintaining the notion of priority and class with-in > cgroup. Also there are multiple pdflush threads and jens seems to be pushing > flusher threads per bdi which will help us achieve greater scalability and > don't have to replicate that infrastructure for kiothrottled also. There's a lot of room for improvements and optimizations in the kiothrottled part, obviously the single-threaded approach is not a definitive solutions. Flusher threads are probably a good solution. But I don't think we need to replicate the pdflush replacement infrastructure for throttled writeback IO. Instead it could be just integrated with the flusher threads, i.e. activate flusher threads only when the request needs to be written to disk according to the dirty memory limit and IO BW limits. I mean, I don't see any critical problem for this part. Instead, preserving the IO priority and IO scheduler logic inside cgroups seems a more critical issue to me. And I'm quite convinced that the right approach for this is to operate at the IO scheduler, but I'm still a little bit skeptical that only operating at the IO scheduler level would resolve all our problems. -Andrea -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
