From mboxrd@z Thu Jan 1 00:00:00 1970 From: Balbir Singh Subject: Re: Too many I/O controller patches Date: Wed, 06 Aug 2008 09:00:07 +0530 Message-ID: <48991ABF.906@linux.vnet.ibm.com> References: <20080804.175126.193692178.ryov@valinux.co.jp> <1217870433.20260.101.camel@nimitz> <489748E6.5080106@gmail.com> <000901c8f6a5$fe64ba30$fb2e2e90$@jp.nec.com> <48981D3B.2020701@gmail.com> <1217953218.10907.25.camel@nimitz> <20080806114425.c0e9b24f.kamezawa.hiroyu@jp.fujitsu.com> Reply-To: balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20080806114425.c0e9b24f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@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: KAMEZAWA Hiroyuki Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, vtaras-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, agk-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org, Dave Hansen , ngupta-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org List-Id: containers.vger.kernel.org S0FNRVpBV0EgSGlyb3l1a2kgd3JvdGU6Cj4gT24gVHVlLCAwNSBBdWcgMjAwOCAwOToyMDoxOCAt MDcwMAo+IERhdmUgSGFuc2VuIDxkYXZlQGxpbnV4LnZuZXQuaWJtLmNvbT4gd3JvdGU6Cj4gCj4+ IE9uIFR1ZSwgMjAwOC0wOC0wNSBhdCAxMToyOCArMDIwMCwgQW5kcmVhIFJpZ2hpIHdyb3RlOgo+ Pj4+IEJ1ZmZlcmVkIHdyaXRlIEkvTyBpcyBhbHNvIHJlbGF0ZWQgd2l0aCBjYWNoZSBzeXN0ZW0u Cj4+Pj4gV2UgbXVzdCBjb25zaWRlciB0aGlzIHByb2JsZW0gYXMgSS9PIGNvbnRyb2wuCj4+PiBB Z3JlZS4gQXQgbGVhc3QsIG1heWJlIHdlIHNob3VsZCBjb25zaWRlciBpZiBhbiBJTyBjb250cm9s bGVyIGNvdWxkIGJlCj4+PiBhIHZhbGlkIHNvbHV0aW9uIGFsc28gZm9yIHRoZXNlIHByb2JsZW1z Lgo+PiBJc24ndCB0aGlzIG9uZSBvZiB0aGUgY29yZSBwb2ludHMgdGhhdCB3ZSBrZWVwIGdvaW5n IGJhY2sgYW5kIGZvcnRoCj4+IG92ZXI/ICDvu79JdCBzZWVtcyBsaWtlIHBlb3BsZSBhcmUgYXJn dWluZyBpbiBjaXJjbGVzIG92ZXIgdGhpczoKPj4KPj4gRG8gd2U6Cj4+IAkxLiBjb250cm9sIHBv dGVudGlhbCBtZW1vcnkgdXNhZ2UgYnkgdGhyb3R0bGluZyBJL08KPj4gb3IKPj4gCTIuIFRocm90 dGxlIEkvTyB3aGVuIG1lbW9yeSBpcyBmdWxsCj4+Cj4+IEkgbWlnaHQgbGVhbiB0b3dhcmQgKDEp IGlmIHdlIGRpZG4ndCBhbHJlYWR5IGhhdmUgYSBtZW1vcnkgY29udHJvbGxlci4KPj4gQnV0LCB3 ZSBoYXZlIG9uZSwgYW5kIGl0IHdvcmtzLiAgQWxzbywgd2UgKmFscmVhZHkqIGRvICgyKSBpbiB0 aGUKPj4ga2VybmVsLCBzbyBpdCB3b3VsZCBzZWVtIHRvIGdyYWZ0IHdlbGwgb250byBleGlzdGlu ZyBtZWNoYW5pc21zIHRoYXQgd2UKPj4gaGF2ZS4KPj4KPj4gSS9PIGNvbnRyb2xsZXJzIHNob3Vs ZCBub3Qgd29ycnkgYWJvdXQgbWVtb3J5LiAgCj4gSSBhZ3JlZSBoZXJlIDspCj4gCj4+IFRoZXkn cmUgZ29pbmcgdG8gaGF2ZSBhIGhhcmQgZW5vdWdoIHRpbWUgZ2V0dGluZyB0aGUgSS9PIHBhcnQg cmlnaHQuIDopCj4+Cj4gbWVtY2cgaGF2ZSBtb3JlIHByb2JsZW1zIG5vdyA7KCAKPiAKPiBPbmx5 IGEgZGlmZmljdWx0IHRoaW5nIHRvIGxpbWl0IGRpcnR5LXJhdGlvIGluIG1lbWNnIGlzIGhvdy10 by1jb3VudCBkaXJ0eQo+IHBhZ2VzLiBJZiBJL08gY29udHJvbGxlcidzIGhvb2sgaGVscHMsIGl0 J3MgZ29vZC4KPiAKPiBNeSBzbWFsbCBjb25jZXJuIGlzICJXaGF0IGhhcHBlbnMgaWYgd2UgdGhy b3R0b2xlIEkvTyBiYW5kd2lkdGggdG9vIHNtYWxsCj4gdW5kZXIgc29tZSBtZW1jZy4iIEluIHN1 Y2ggY2dyb3VwLCB3ZSBtYXkgc2VlIG1vcmUgT09NcyBiZWNhdXNlIEkvTyB3aWxsCj4gbm90IGZp bmlzaCBpbiB0aW1lLgo+IEEgc3lzdGVtIGFkbWluIGhhdmUgdG8gZmluZCBzb21lIHdheSB0byBh dm9pZCB0aGlzLgo+IAo+IEJ1dCBwbGVhc2UgZG8gSS9PIGNvbnRyb2wgZmlyc3QuIERpcnR5LXBh Z2UgY29udHJvbCBpcyByZWxhdGVkIGJ1dCBkaWZmZXJlbnQKPiBsYXllcidzIHByb2JsZW0sIEkg dGhpbmsuCgpZZXMsIHBsZWFzZSBzb2x2ZSB0aGUgSS9PIGNvbnRyb2wgcHJvYmxlbSBmaXJzdC4K Ci0tIAoJV2FybSBSZWdhcmRzLAoJQmFsYmlyIFNpbmdoCglMaW51eCBUZWNobm9sb2d5IENlbnRl cgoJSUJNLCBJU1RMCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpDb250YWluZXJzIG1haWxpbmcgbGlzdApDb250YWluZXJzQGxpc3RzLmxpbnV4LWZvdW5k YXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb250YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764053AbYHFDbd (ORCPT ); Tue, 5 Aug 2008 23:31:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751867AbYHFDaQ (ORCPT ); Tue, 5 Aug 2008 23:30:16 -0400 Received: from E23SMTP02.au.ibm.com ([202.81.18.163]:46220 "EHLO e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbYHFDaO convert rfc822-to-8bit (ORCPT ); Tue, 5 Aug 2008 23:30:14 -0400 Message-ID: <48991ABF.906@linux.vnet.ibm.com> Date: Wed, 06 Aug 2008 09:00:07 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com Organization: IBM User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: KAMEZAWA Hiroyuki CC: Dave Hansen , xen-devel@lists.xensource.com, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, vtaras@openvz.org, dm-devel@redhat.com, agk@sourceware.org, ngupta@google.com, righi.andrea@gmail.com Subject: Re: Too many I/O controller patches References: <20080804.175126.193692178.ryov@valinux.co.jp> <1217870433.20260.101.camel@nimitz> <489748E6.5080106@gmail.com> <000901c8f6a5$fe64ba30$fb2e2e90$@jp.nec.com> <48981D3B.2020701@gmail.com> <1217953218.10907.25.camel@nimitz> <20080806114425.c0e9b24f.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20080806114425.c0e9b24f.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org KAMEZAWA Hiroyuki wrote: > On Tue, 05 Aug 2008 09:20:18 -0700 > Dave Hansen wrote: > >> On Tue, 2008-08-05 at 11:28 +0200, Andrea Righi wrote: >>>> Buffered write I/O is also related with cache system. >>>> We must consider this problem as I/O control. >>> Agree. At least, maybe we should consider if an IO controller could be >>> a valid solution also for these problems. >> Isn't this one of the core points that we keep going back and forth >> over? It seems like people are arguing in circles over this: >> >> Do we: >> 1. control potential memory usage by throttling I/O >> or >> 2. Throttle I/O when memory is full >> >> I might lean toward (1) if we didn't already have a memory controller. >> But, we have one, and it works. Also, we *already* do (2) in the >> kernel, so it would seem to graft well onto existing mechanisms that we >> have. >> >> I/O controllers should not worry about memory. > I agree here ;) > >> They're going to have a hard enough time getting the I/O part right. :) >> > memcg have more problems now ;( > > Only a difficult thing to limit dirty-ratio in memcg is how-to-count dirty > pages. If I/O controller's hook helps, it's good. > > My small concern is "What happens if we throttole I/O bandwidth too small > under some memcg." In such cgroup, we may see more OOMs because I/O will > not finish in time. > A system admin have to find some way to avoid this. > > But please do I/O control first. Dirty-page control is related but different > layer's problem, I think. Yes, please solve the I/O control problem first. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL