From: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Carl Henrik Lunde <chlunde-om2ZC0WAoZIXWF+eFR7m5Q@public.gmane.org>, eric.rannaud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Balbir Singh <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, Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org>, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@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 Subject: Re: [PATCH 1/9] io-throttle documentation Date: Tue, 21 Apr 2009 14:29:58 -0400 [thread overview] Message-ID: <20090421182958.GF22619@redhat.com> (raw) In-Reply-To: <20090421142305.GB22619-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> On Tue, Apr 21, 2009 at 10:23:05AM -0400, Vivek Goyal wrote: > On Tue, Apr 21, 2009 at 10:37:03AM +0200, Andrea Righi wrote: > > On Mon, Apr 20, 2009 at 09:08:46PM -0400, Vivek Goyal wrote: > > > On Tue, Apr 21, 2009 at 12:05:12AM +0200, Andrea Righi wrote: > > > > > > [..] > > > > > > > Are we not already controlling submission of request (at crude level). > > > > > > > If application is doing writeout at high rate, then it hits vm_dirty_ratio > > > > > > > hits and this application is forced to do write out and hence it is slowed > > > > > > > down and is not allowed to submit writes at high rate. > > > > > > > > > > > > > > Just that it is not a very fair scheme right now as during right out > > > > > > > a high prio/high weight cgroup application can start writing out some > > > > > > > other cgroups' pages. > > > > > > > > > > > > > > For this we probably need to have some combination of solutions like > > > > > > > per cgroup upper limit on dirty pages. Secondly probably if an application > > > > > > > is slowed down because of hitting vm_drity_ratio, it should try to > > > > > > > write out the inode it is dirtying first instead of picking any random > > > > > > > inode and associated pages. This will ensure that a high weight > > > > > > > application can quickly get through the write outs and see higher > > > > > > > throughput from the disk. > > > > > > > > > > > > For the first, I submitted a patchset some months ago to provide this > > > > > > feature in the memory controller: > > > > > > > > > > > > https://lists.linux-foundation.org/pipermail/containers/2008-September/013140.html > > > > > > > > > > > > We focused on the best interface to use for setting the dirty pages > > > > > > limit, but we didn't finalize it. I can rework on that and repost an > > > > > > updated version. Now that we have the dirty_ratio/dirty_bytes to set the > > > > > > global limit I think we can use the same interface and the same semantic > > > > > > within the cgroup fs, something like: > > > > > > > > > > > > memory.dirty_ratio > > > > > > memory.dirty_bytes > > > > > > > > > > > > For the second point something like this should be enough to force tasks > > > > > > to write out only the inode they're actually dirtying when they hit the > > > > > > vm_dirty_ratio limit. But it should be tested carefully and may cause > > > > > > heavy performance regressions. > > > > > > > > > > > > Signed-off-by: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > > > > --- > > > > > > mm/page-writeback.c | 2 +- > > > > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > > > > > > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > > > > > > index 2630937..1e07c9d 100644 > > > > > > --- a/mm/page-writeback.c > > > > > > +++ b/mm/page-writeback.c > > > > > > @@ -543,7 +543,7 @@ static void balance_dirty_pages(struct address_space *mapping) > > > > > > * been flushed to permanent storage. > > > > > > */ > > > > > > if (bdi_nr_reclaimable) { > > > > > > - writeback_inodes(&wbc); > > > > > > + sync_inode(mapping->host, &wbc); > > > > > > pages_written += write_chunk - wbc.nr_to_write; > > > > > > get_dirty_limits(&background_thresh, &dirty_thresh, > > > > > > &bdi_thresh, bdi); > > > > > > > > > > This patch seems to be helping me a bit in getting more service > > > > > differentiation between two writer dd of different weights. But strangely > > > > > it is helping only for ext3 and not ext4. Debugging is on. > > > > > > > > Are you explicitly mounting ext3 with data=ordered? > > > > > > Yes. Still using 29-rc8 and data=ordered was the default then. > > > > > > I got two partitions on same disk and created one ext3 filesystem on each > > > partition (just to take journaling intereference out of two dd threads > > > for the time being). > > > > > > Two dd threads doing writes to each partition. > > > > ...and if you're using data=writeback with ext4 sync_inode() should sync > > the metadata only. If this is the case, could you check data=ordered > > also for ext4? > > No, even data=ordered mode with ext4 is also not helping. It has to be > something else. > Ok, with data=ordered mode with ext4, now I can get significant service differentiation between two dd processes. I had to tweak cfq a bit. - Instead of 40ms slice for async queue, do 20ms at a time (tunable). - change cfq quantum to 1 from 4 to not dispatch a bunch of requests at one go. Above changes help a bit in making sure two continuously backlogged queues at IO scheduler so that IO scheduler can offer more disk time to higher weight process. Thanks Vivek > BTW, with the above patch, what happens if the address space being dirtied > does not have sufficient dirty pages to write back (more than write_chunk). > Will the process not be in loop until the number of dirty pages come down > (hopefully due to writeout by pdflush or by other processes?) > > Thanks > Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: Andrea Righi <righi.andrea@gmail.com> Cc: Paul Menage <menage@google.com>, Balbir Singh <balbir@linux.vnet.ibm.com>, Gui Jianfeng <guijianfeng@cn.fujitsu.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, agk@sourceware.org, akpm@linux-foundation.org, axboe@kernel.dk, baramsori72@gmail.com, Carl Henrik Lunde <chlunde@ping.uio.no>, dave@linux.vnet.ibm.com, Divyesh Shah <dpshah@google.com>, eric.rannaud@gmail.com, fernando@oss.ntt.co.jp, Hirokazu Takahashi <taka@valinux.co.jp>, Li Zefan <lizf@cn.fujitsu.com>, matt@bluehost.com, dradford@bluehost.com, ngupta@google.com, randy.dunlap@oracle.com, roberto@unbit.it, Ryo Tsuruta <ryov@valinux.co.jp>, Satoshi UCHIDA <s-uchida@ap.jp.nec.com>, subrata@linux.vnet.ibm.com, yoshikawa.takuya@oss.ntt.co.jp, Theodore Tso <tytso@mit.edu>, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/9] io-throttle documentation Date: Tue, 21 Apr 2009 14:29:58 -0400 [thread overview] Message-ID: <20090421182958.GF22619@redhat.com> (raw) In-Reply-To: <20090421142305.GB22619@redhat.com> On Tue, Apr 21, 2009 at 10:23:05AM -0400, Vivek Goyal wrote: > On Tue, Apr 21, 2009 at 10:37:03AM +0200, Andrea Righi wrote: > > On Mon, Apr 20, 2009 at 09:08:46PM -0400, Vivek Goyal wrote: > > > On Tue, Apr 21, 2009 at 12:05:12AM +0200, Andrea Righi wrote: > > > > > > [..] > > > > > > > Are we not already controlling submission of request (at crude level). > > > > > > > If application is doing writeout at high rate, then it hits vm_dirty_ratio > > > > > > > hits and this application is forced to do write out and hence it is slowed > > > > > > > down and is not allowed to submit writes at high rate. > > > > > > > > > > > > > > Just that it is not a very fair scheme right now as during right out > > > > > > > a high prio/high weight cgroup application can start writing out some > > > > > > > other cgroups' pages. > > > > > > > > > > > > > > For this we probably need to have some combination of solutions like > > > > > > > per cgroup upper limit on dirty pages. Secondly probably if an application > > > > > > > is slowed down because of hitting vm_drity_ratio, it should try to > > > > > > > write out the inode it is dirtying first instead of picking any random > > > > > > > inode and associated pages. This will ensure that a high weight > > > > > > > application can quickly get through the write outs and see higher > > > > > > > throughput from the disk. > > > > > > > > > > > > For the first, I submitted a patchset some months ago to provide this > > > > > > feature in the memory controller: > > > > > > > > > > > > https://lists.linux-foundation.org/pipermail/containers/2008-September/013140.html > > > > > > > > > > > > We focused on the best interface to use for setting the dirty pages > > > > > > limit, but we didn't finalize it. I can rework on that and repost an > > > > > > updated version. Now that we have the dirty_ratio/dirty_bytes to set the > > > > > > global limit I think we can use the same interface and the same semantic > > > > > > within the cgroup fs, something like: > > > > > > > > > > > > memory.dirty_ratio > > > > > > memory.dirty_bytes > > > > > > > > > > > > For the second point something like this should be enough to force tasks > > > > > > to write out only the inode they're actually dirtying when they hit the > > > > > > vm_dirty_ratio limit. But it should be tested carefully and may cause > > > > > > heavy performance regressions. > > > > > > > > > > > > Signed-off-by: Andrea Righi <righi.andrea@gmail.com> > > > > > > --- > > > > > > mm/page-writeback.c | 2 +- > > > > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > > > > > > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > > > > > > index 2630937..1e07c9d 100644 > > > > > > --- a/mm/page-writeback.c > > > > > > +++ b/mm/page-writeback.c > > > > > > @@ -543,7 +543,7 @@ static void balance_dirty_pages(struct address_space *mapping) > > > > > > * been flushed to permanent storage. > > > > > > */ > > > > > > if (bdi_nr_reclaimable) { > > > > > > - writeback_inodes(&wbc); > > > > > > + sync_inode(mapping->host, &wbc); > > > > > > pages_written += write_chunk - wbc.nr_to_write; > > > > > > get_dirty_limits(&background_thresh, &dirty_thresh, > > > > > > &bdi_thresh, bdi); > > > > > > > > > > This patch seems to be helping me a bit in getting more service > > > > > differentiation between two writer dd of different weights. But strangely > > > > > it is helping only for ext3 and not ext4. Debugging is on. > > > > > > > > Are you explicitly mounting ext3 with data=ordered? > > > > > > Yes. Still using 29-rc8 and data=ordered was the default then. > > > > > > I got two partitions on same disk and created one ext3 filesystem on each > > > partition (just to take journaling intereference out of two dd threads > > > for the time being). > > > > > > Two dd threads doing writes to each partition. > > > > ...and if you're using data=writeback with ext4 sync_inode() should sync > > the metadata only. If this is the case, could you check data=ordered > > also for ext4? > > No, even data=ordered mode with ext4 is also not helping. It has to be > something else. > Ok, with data=ordered mode with ext4, now I can get significant service differentiation between two dd processes. I had to tweak cfq a bit. - Instead of 40ms slice for async queue, do 20ms at a time (tunable). - change cfq quantum to 1 from 4 to not dispatch a bunch of requests at one go. Above changes help a bit in making sure two continuously backlogged queues at IO scheduler so that IO scheduler can offer more disk time to higher weight process. Thanks Vivek > BTW, with the above patch, what happens if the address space being dirtied > does not have sufficient dirty pages to write back (more than write_chunk). > Will the process not be in loop until the number of dirty pages come down > (hopefully due to writeout by pdflush or by other processes?) > > Thanks > Vivek
next prev parent reply other threads:[~2009-04-21 18:29 UTC|newest] Thread overview: 207+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-04-14 20:21 [PATCH 0/9] cgroup: io-throttle controller (v13) Andrea Righi [not found] ` <1239740480-28125-1-git-send-email-righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2009-04-14 20:21 ` [PATCH 1/9] io-throttle documentation Andrea Righi 2009-04-14 20:21 ` Andrea Righi 2009-04-17 1:24 ` KAMEZAWA Hiroyuki 2009-04-17 1:56 ` Li Zefan 2009-04-17 10:25 ` Andrea Righi 2009-04-17 10:41 ` Andrea Righi 2009-04-17 10:41 ` Andrea Righi 2009-04-17 11:35 ` Fernando Luis Vázquez Cao 2009-04-17 11:35 ` Fernando Luis Vázquez Cao 2009-04-20 9:38 ` Ryo Tsuruta 2009-04-20 9:38 ` Ryo Tsuruta [not found] ` <20090420.183815.226804723.ryov-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> 2009-04-20 15:00 ` Andrea Righi 2009-04-20 15:00 ` Andrea Righi 2009-04-27 10:45 ` Ryo Tsuruta 2009-04-27 12:15 ` Ryo Tsuruta [not found] ` <20090427.194533.183037823.ryov-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> 2009-04-27 12:15 ` Ryo Tsuruta 2009-04-27 21:56 ` Andrea Righi 2009-04-27 21:56 ` Andrea Righi 2009-04-27 10:45 ` Ryo Tsuruta [not found] ` <49E7E1CF.6060209-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> 2009-04-17 10:25 ` Andrea Righi 2009-04-17 7:34 ` Gui Jianfeng 2009-04-17 7:43 ` KAMEZAWA Hiroyuki 2009-04-17 9:29 ` Gui Jianfeng [not found] ` <20090417164351.ea85012d.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 9:29 ` Gui Jianfeng [not found] ` <49E8311D.5030901-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> 2009-04-17 7:43 ` KAMEZAWA Hiroyuki [not found] ` <20090417102417.88a0ef93.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 1:56 ` Li Zefan 2009-04-17 7:34 ` Gui Jianfeng 2009-04-17 9:55 ` Andrea Righi 2009-04-17 9:55 ` Andrea Righi [not found] ` <1239740480-28125-2-git-send-email-righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2009-04-17 1:24 ` KAMEZAWA Hiroyuki 2009-04-17 17:39 ` Vivek Goyal 2009-04-17 17:39 ` Vivek Goyal 2009-04-17 23:12 ` Andrea Righi 2009-04-19 13:42 ` Vivek Goyal 2009-04-19 13:42 ` Vivek Goyal [not found] ` <20090419134201.GF8493-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2009-04-19 15:47 ` Andrea Righi 2009-04-19 15:47 ` Andrea Righi 2009-04-20 21:28 ` Vivek Goyal 2009-04-20 21:28 ` Vivek Goyal 2009-04-20 22:05 ` Andrea Righi 2009-04-21 1:08 ` Vivek Goyal 2009-04-21 1:08 ` Vivek Goyal [not found] ` <20090421010846.GA15850-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2009-04-21 8:37 ` Andrea Righi 2009-04-21 8:37 ` Andrea Righi 2009-04-21 14:23 ` Vivek Goyal 2009-04-21 14:23 ` Vivek Goyal [not found] ` <20090421142305.GB22619-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2009-04-21 18:29 ` Vivek Goyal [this message] 2009-04-21 18:29 ` Vivek Goyal [not found] ` <20090421182958.GF22619-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2009-04-21 21:36 ` Andrea Righi 2009-04-21 21:36 ` Andrea Righi 2009-04-21 21:28 ` Andrea Righi 2009-04-21 21:28 ` Andrea Righi [not found] ` <20090420212827.GA9080-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2009-04-20 22:05 ` Andrea Righi 2009-04-19 13:54 ` Vivek Goyal 2009-04-19 13:54 ` Vivek Goyal [not found] ` <20090417173955.GF29086-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2009-04-17 23:12 ` Andrea Righi 2009-04-14 20:21 ` [PATCH 2/9] res_counter: introduce ratelimiting attributes Andrea Righi 2009-04-14 20:21 ` Andrea Righi 2009-04-14 20:21 ` [PATCH 3/9] bio-cgroup controller Andrea Righi 2009-04-14 20:21 ` Andrea Righi 2009-04-15 2:15 ` KAMEZAWA Hiroyuki 2009-04-15 9:37 ` Andrea Righi 2009-04-15 12:38 ` Ryo Tsuruta [not found] ` <20090415.213850.226770691.ryov-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> 2009-04-15 13:23 ` Andrea Righi 2009-04-15 13:23 ` Andrea Righi 2009-04-15 23:58 ` KAMEZAWA Hiroyuki 2009-04-15 23:58 ` KAMEZAWA Hiroyuki 2009-04-16 10:42 ` Andrea Righi 2009-04-16 12:00 ` Ryo Tsuruta 2009-04-16 12:00 ` Ryo Tsuruta 2009-04-17 0:04 ` KAMEZAWA Hiroyuki 2009-04-17 9:44 ` Andrea Righi [not found] ` <20090417090451.5ad9022f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 9:44 ` Andrea Righi 2009-04-17 0:04 ` KAMEZAWA Hiroyuki [not found] ` <20090416085814.8b6d077f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-16 10:42 ` Andrea Righi 2009-04-15 12:38 ` Ryo Tsuruta 2009-04-15 13:07 ` Andrea Righi [not found] ` <20090415111528.b796519a.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-15 9:37 ` Andrea Righi 2009-04-15 13:07 ` Andrea Righi 2009-04-16 22:29 ` Andrew Morton 2009-04-17 0:20 ` KAMEZAWA Hiroyuki [not found] ` <20090417092040.1c832c69.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 0:44 ` Andrew Morton 2009-04-17 0:44 ` Andrew Morton 2009-04-17 1:44 ` Ryo Tsuruta 2009-04-17 4:15 ` Andrew Morton [not found] ` <20090416211514.038c5e91.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2009-04-17 7:48 ` Ryo Tsuruta 2009-04-17 7:48 ` Ryo Tsuruta [not found] ` <20090417.104432.193700511.ryov-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> 2009-04-17 4:15 ` Andrew Morton 2009-04-17 1:50 ` Balbir Singh [not found] ` <20090416174428.6bb5da21.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2009-04-17 1:44 ` Ryo Tsuruta 2009-04-17 1:50 ` Balbir Singh [not found] ` <20090416152937.b2188370.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2009-04-17 0:20 ` KAMEZAWA Hiroyuki 2009-04-17 9:40 ` Andrea Righi 2009-04-17 9:40 ` Andrea Righi 2009-04-17 1:49 ` Takuya Yoshikawa 2009-04-17 2:24 ` KAMEZAWA Hiroyuki [not found] ` <20090417112433.085ed604.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 7:22 ` Ryo Tsuruta 2009-04-17 7:22 ` Ryo Tsuruta 2009-04-17 8:00 ` KAMEZAWA Hiroyuki [not found] ` <20090417170016.5c7268f1.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 8:48 ` KAMEZAWA Hiroyuki 2009-04-17 8:48 ` KAMEZAWA Hiroyuki [not found] ` <20090417174854.07aeec9f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-17 8:51 ` KAMEZAWA Hiroyuki 2009-04-17 8:51 ` KAMEZAWA Hiroyuki [not found] ` <20090417.162201.183038478.ryov-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> 2009-04-17 8:00 ` KAMEZAWA Hiroyuki 2009-04-17 11:27 ` Block I/O tracking (was Re: [PATCH 3/9] bio-cgroup controller) Fernando Luis Vázquez Cao 2009-04-17 11:27 ` Fernando Luis Vázquez Cao 2009-04-17 22:09 ` Andrea Righi [not found] ` <49E8679D.8010405-gVGce1chcLdL9jVzuh4AOg@public.gmane.org> 2009-04-17 22:09 ` Andrea Righi 2009-04-17 7:32 ` [PATCH 3/9] bio-cgroup controller Ryo Tsuruta [not found] ` <49E7E037.9080004-gVGce1chcLdL9jVzuh4AOg@public.gmane.org> 2009-04-17 2:24 ` KAMEZAWA Hiroyuki 2009-04-17 7:32 ` Ryo Tsuruta 2009-04-17 10:22 ` Balbir Singh [not found] ` <20090417102214.GC3896-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2009-04-20 11:35 ` Ryo Tsuruta 2009-04-20 11:35 ` Ryo Tsuruta [not found] ` <20090420.203540.104031006.ryov-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> 2009-04-20 14:56 ` Andrea Righi 2009-04-20 14:56 ` Andrea Righi 2009-04-21 11:39 ` Ryo Tsuruta 2009-04-21 11:39 ` Ryo Tsuruta 2009-04-21 15:31 ` Balbir Singh 2009-04-21 15:31 ` Balbir Singh [not found] ` <1239740480-28125-4-git-send-email-righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2009-04-15 2:15 ` KAMEZAWA Hiroyuki 2009-04-16 22:29 ` Andrew Morton 2009-04-17 1:49 ` Takuya Yoshikawa 2009-04-17 10:22 ` Balbir Singh 2009-04-14 20:21 ` [PATCH 4/9] support checking of cgroup subsystem dependencies Andrea Righi 2009-04-14 20:21 ` [PATCH 5/9] io-throttle controller infrastructure Andrea Righi 2009-04-14 20:21 ` [PATCH 6/9] kiothrottled: throttle buffered (writeback) IO Andrea Righi 2009-04-14 20:21 ` Andrea Righi 2009-04-14 20:21 ` [PATCH 7/9] io-throttle instrumentation Andrea Righi 2009-04-14 20:21 ` Andrea Righi 2009-04-14 20:21 ` [PATCH 8/9] export per-task io-throttle statistics to userspace Andrea Righi 2009-04-14 20:21 ` Andrea Righi 2009-04-14 20:21 ` [PATCH 9/9] ext3: do not throttle metadata and journal IO Andrea Righi 2009-04-14 20:21 ` Andrea Righi [not found] ` <1239740480-28125-10-git-send-email-righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2009-04-17 12:38 ` Theodore Tso 2009-04-17 12:38 ` Theodore Tso 2009-04-17 12:50 ` Jens Axboe [not found] ` <20090417125004.GY4593-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org> 2009-04-17 14:39 ` Andrea Righi 2009-04-17 14:39 ` Andrea Righi 2009-04-21 0:18 ` Theodore Tso 2009-04-21 8:30 ` Andrea Righi 2009-04-21 14:06 ` Theodore Tso 2009-04-21 14:31 ` Andrea Righi 2009-04-21 16:35 ` Theodore Tso [not found] ` <20090421163537.GI19186-3s7WtUTddSA@public.gmane.org> 2009-04-21 17:23 ` Balbir Singh 2009-04-21 17:23 ` Balbir Singh [not found] ` <20090421172317.GM19637-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2009-04-21 17:46 ` Theodore Tso 2009-04-21 17:46 ` Theodore Tso [not found] ` <20090421174620.GD15541-3s7WtUTddSA@public.gmane.org> 2009-04-21 18:14 ` Balbir Singh 2009-04-21 18:14 ` Balbir Singh 2009-04-21 19:14 ` Theodore Tso [not found] ` <20090421191401.GF15541-3s7WtUTddSA@public.gmane.org> 2009-04-21 20:49 ` Andrea Righi 2009-04-22 3:30 ` Balbir Singh 2009-04-21 20:49 ` Andrea Righi 2009-04-22 0:33 ` KAMEZAWA Hiroyuki 2009-04-22 1:21 ` KAMEZAWA Hiroyuki [not found] ` <20090422102153.9aec17b9.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-22 10:22 ` Andrea Righi 2009-04-22 10:22 ` Andrea Righi 2009-04-23 0:05 ` KAMEZAWA Hiroyuki 2009-04-23 1:22 ` Theodore Tso [not found] ` <20090423012254.GZ15541-3s7WtUTddSA@public.gmane.org> 2009-04-23 2:54 ` KAMEZAWA Hiroyuki 2009-04-23 2:54 ` KAMEZAWA Hiroyuki [not found] ` <20090423115419.c493266a.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-23 4:35 ` Theodore Tso 2009-04-23 4:35 ` Theodore Tso [not found] ` <20090423043547.GB2723-3s7WtUTddSA@public.gmane.org> 2009-04-23 4:58 ` Andrew Morton 2009-04-23 4:58 ` Andrew Morton 2009-04-23 5:37 ` KAMEZAWA Hiroyuki [not found] ` <20090422215825.f83e1b27.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2009-04-23 5:37 ` KAMEZAWA Hiroyuki 2009-04-23 9:44 ` Andrea Righi 2009-04-24 5:14 ` Balbir Singh 2009-04-23 9:44 ` Andrea Righi 2009-04-23 12:17 ` Theodore Tso 2009-04-23 12:17 ` Theodore Tso [not found] ` <20090423121745.GC2723-3s7WtUTddSA@public.gmane.org> 2009-04-23 12:27 ` Theodore Tso 2009-04-23 12:27 ` Theodore Tso 2009-04-23 21:13 ` Andrea Righi 2009-04-23 21:13 ` Andrea Righi 2009-04-24 0:26 ` KAMEZAWA Hiroyuki 2009-04-24 0:26 ` KAMEZAWA Hiroyuki 2009-04-24 5:14 ` Balbir Singh 2009-04-23 10:03 ` Andrea Righi [not found] ` <20090423090535.ec419269.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-23 1:22 ` Theodore Tso 2009-04-23 10:03 ` Andrea Righi 2009-04-23 0:05 ` KAMEZAWA Hiroyuki [not found] ` <20090422093349.1ee9ae82.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-04-22 1:21 ` KAMEZAWA Hiroyuki 2009-04-22 0:33 ` KAMEZAWA Hiroyuki 2009-04-22 3:30 ` Balbir Singh [not found] ` <20090421181429.GO19637-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2009-04-21 19:14 ` Theodore Tso 2009-04-21 16:35 ` Theodore Tso [not found] ` <20090421140631.GF19186-3s7WtUTddSA@public.gmane.org> 2009-04-21 14:31 ` Andrea Righi 2009-04-24 15:10 ` Balbir Singh 2009-04-24 15:10 ` Balbir Singh 2009-04-21 14:06 ` Theodore Tso [not found] ` <20090421001822.GB19186-3s7WtUTddSA@public.gmane.org> 2009-04-21 8:30 ` Andrea Righi 2009-04-21 0:18 ` Theodore Tso [not found] ` <20090417123805.GC7117-3s7WtUTddSA@public.gmane.org> 2009-04-17 12:50 ` Jens Axboe 2009-04-16 22:24 ` [PATCH 0/9] cgroup: io-throttle controller (v13) Andrew Morton 2009-04-16 22:24 ` Andrew Morton [not found] ` <20090416152433.aaaba300.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2009-04-17 9:37 ` Andrea Righi 2009-04-17 9:37 ` Andrea Righi 2009-04-30 13:20 ` Alan D. Brunelle 2009-04-14 20:21 ` [PATCH 4/9] support checking of cgroup subsystem dependencies Andrea Righi 2009-04-14 20:21 ` [PATCH 5/9] io-throttle controller infrastructure Andrea Righi 2009-04-30 13:20 ` [PATCH 0/9] cgroup: io-throttle controller (v13) Alan D. Brunelle [not found] ` <49F9A5BA.9030100-VXdhtT5mjnY@public.gmane.org> 2009-05-01 11:11 ` Andrea Righi 2009-05-01 11:11 ` Andrea Righi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090421182958.GF22619@redhat.com \ --to=vgoyal-h+wxahxf7alqt0dzr+alfa@public.gmane.org \ --cc=agk-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org \ --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \ --cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \ --cc=balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \ --cc=chlunde-om2ZC0WAoZIXWF+eFR7m5Q@public.gmane.org \ --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \ --cc=dradford-cT2on/YLNlBWk0Htik3J/w@public.gmane.org \ --cc=eric.rannaud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=fernando-gVGce1chcLdL9jVzuh4AOg@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=matt-cT2on/YLNlBWk0Htik3J/w@public.gmane.org \ --cc=menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=ngupta-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \ --cc=righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=roberto-5KDOxZqKugI@public.gmane.org \ --cc=subrata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \ --cc=tytso-3s7WtUTddSA@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.