From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932586Ab2DDXCp (ORCPT ); Wed, 4 Apr 2012 19:02:45 -0400 Received: from mail-pz0-f52.google.com ([209.85.210.52]:39160 "EHLO mail-pz0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757369Ab2DDXCn (ORCPT ); Wed, 4 Apr 2012 19:02:43 -0400 Date: Wed, 4 Apr 2012 16:02:37 -0700 From: Tejun Heo To: Vivek Goyal Cc: Fengguang Wu , Jan Kara , Jens Axboe , linux-mm@kvack.org, sjayaraman@suse.com, andrea@betterlinux.com, jmoyer@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, lizefan@huawei.com, containers@lists.linux-foundation.org, cgroups@vger.kernel.org, ctalbott@google.com, rni@google.com, lsf@lists.linux-foundation.org Subject: Re: [RFC] writeback and cgroup Message-ID: <20120404230237.GA2173@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-Disposition: inline In-Reply-To: <20120404203239.GM12676@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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 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@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 Cc: Fengguang Wu , Jan Kara , Jens Axboe , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, sjayaraman-IBi9RG/b67k@public.gmane.org, andrea-oIIqvOZpAevzfdHfmsDf5w@public.gmane.org, jmoyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ctalbott-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, rni-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, lsf-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Vivek Goyal Return-path: Content-Disposition: inline In-Reply-To: <20120404203239.GM12676-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx139.postini.com [74.125.245.139]) by kanga.kvack.org (Postfix) with SMTP id EE3526B00FA for ; Wed, 4 Apr 2012 19:02:43 -0400 (EDT) Received: by pbcup15 with SMTP id up15so956383pbc.14 for ; Wed, 04 Apr 2012 16:02:43 -0700 (PDT) Date: Wed, 4 Apr 2012 16:02:37 -0700 From: Tejun Heo Subject: Re: [RFC] writeback and cgroup Message-ID: <20120404230237.GA2173@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-Disposition: inline In-Reply-To: <20120404203239.GM12676@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Vivek Goyal Cc: Fengguang Wu , Jan Kara , Jens Axboe , linux-mm@kvack.org, sjayaraman@suse.com, andrea@betterlinux.com, jmoyer@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, lizefan@huawei.com, containers@lists.linux-foundation.org, cgroups@vger.kernel.org, ctalbott@google.com, rni@google.com, lsf@lists.linux-foundation.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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org