From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC] writeback and cgroup Date: Wed, 4 Apr 2012 16:02:37 -0700 Message-ID: <20120404230237.GA2173__13985.6743081056$1333580575$gmane$org@dhcp-172-17-108-109.mtv.corp.google.com> References: <20120403183655.GA23106@dhcp-172-17-108-109.mtv.corp.google.com> <20120404145134.GC12676@redhat.com> <20120404184909.GB29686@dhcp-172-17-108-109.mtv.corp.google.com> <20120404203239.GM12676@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120404203239.GM12676-H+wXaHxf7aLQT0dZR+AlfA@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: Vivek Goyal Cc: Jens Axboe , ctalbott-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, Jan Kara , rni-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, andrea-oIIqvOZpAevzfdHfmsDf5w@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sjayaraman-IBi9RG/b67k@public.gmane.org, lsf-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, jmoyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fengguang Wu List-Id: containers.vger.kernel.org Hello, Vivek. On Wed, Apr 04, 2012 at 04:32:39PM -0400, Vivek Goyal wrote: > > Let's say we have iops/bps limitation applied on top of proportional IO > > distribution > > We already do that. First IO is subjected to throttling limit and only > then it is passed to the elevator to do the proportional IO. So throttling > is already stacked on top of proportional IO. The only question is > should it be pushed to even higher layers or not. Yeah, I know we already can do that. I was trying to give an example of non-trivial IO limit configuration. > So split model is definitely confusing. Anyway, block layer will not > apply the limits again as flusher IO will go in root cgroup which > generally goes to root which is unthrottled generally. Or flusher > could mark the bios with a flag saying "do not throttle" bios again as > these have been throttled already. So throttling again is probably not > an issue. > > In summary, agreed that split is confusing and it fills a gap existing > today. It's not only confusing. It's broken. So, what you're saying is that there's no provision to orchestrate between buffered writes and other types of IOs. So, it would essentially work as if there are two separate controls controlling each of two heavily interacting parts with no designed provision between them. What the.... -- tejun