From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 0/9] cgroup: io-throttle controller (v13) Date: Thu, 16 Apr 2009 15:24:33 -0700 Message-ID: <20090416152433.aaaba300.akpm@linux-foundation.org> References: <1239740480-28125-1-git-send-email-righi.andrea@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1239740480-28125-1-git-send-email-righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Andrea Righi Cc: randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, chlunde-om2ZC0WAoZIXWF+eFR7m5Q@public.gmane.org, eric.rannaud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, fernando-gVGce1chcLdL9jVzuh4AOg@public.gmane.org, dradford-cT2on/YLNlBWk0Htik3J/w@public.gmane.org, agk-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org, subrata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, matt-cT2on/YLNlBWk0Htik3J/w@public.gmane.org, roberto-5KDOxZqKugI@public.gmane.org, ngupta-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org List-Id: containers.vger.kernel.org On Tue, 14 Apr 2009 22:21:11 +0200 Andrea Righi 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?