From: Vivek Goyal <vgoyal@redhat.com> To: Andrea Righi <arighi@develer.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>, Balbir Singh <balbir@linux.vnet.ibm.com>, Peter Zijlstra <peterz@infradead.org>, Trond Myklebust <trond.myklebust@fys.uio.no>, Suleiman Souhlal <suleiman@google.com>, Greg Thelen <gthelen@google.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, Andrew Morton <akpm@linux-foundation.org>, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v7) Date: Mon, 15 Mar 2010 13:12:09 -0400 [thread overview] Message-ID: <20100315171209.GI21127@redhat.com> (raw) In-Reply-To: <1268609202-15581-1-git-send-email-arighi@develer.com> On Mon, Mar 15, 2010 at 12:26:37AM +0100, Andrea Righi wrote: > Control the maximum amount of dirty pages a cgroup can have at any given time. > > Per cgroup dirty limit is like fixing the max amount of dirty (hard to reclaim) > page cache used by any cgroup. So, in case of multiple cgroup writers, they > will not be able to consume more than their designated share of dirty pages and > will be forced to perform write-out if they cross that limit. > For me even with this version I see that group with 100M limit is getting much more BW. root cgroup ========== #time dd if=/dev/zero of=/root/zerofile bs=4K count=1M 4294967296 bytes (4.3 GB) copied, 55.7979 s, 77.0 MB/s real 0m56.209s test1 cgroup with memory limit of 100M ====================================== # time dd if=/dev/zero of=/root/zerofile1 bs=4K count=1M 4294967296 bytes (4.3 GB) copied, 20.9252 s, 205 MB/s real 0m21.096s Note, these two jobs are not running in parallel. These are running one after the other. Vivek > The overall design is the following: > > - account dirty pages per cgroup > - limit the number of dirty pages via memory.dirty_ratio / memory.dirty_bytes > and memory.dirty_background_ratio / memory.dirty_background_bytes in > cgroupfs > - start to write-out (background or actively) when the cgroup limits are > exceeded > > This feature is supposed to be strictly connected to any underlying IO > controller implementation, so we can stop increasing dirty pages in VM layer > and enforce a write-out before any cgroup will consume the global amount of > dirty pages defined by the /proc/sys/vm/dirty_ratio|dirty_bytes and > /proc/sys/vm/dirty_background_ratio|dirty_background_bytes limits. > > Changelog (v6 -> v7) > ~~~~~~~~~~~~~~~~~~~~~~ > * introduce trylock_page_cgroup() to guarantee that lock_page_cgroup() > is never called under tree_lock (no strict accounting, but better overall > performance) > * do not account file cache statistics for the root cgroup (zero > overhead for the root cgroup) > * fix: evaluate cgroup free pages as at the minimum free pages of all > its parents > > Results > ~~~~~~~ > The testcase is a kernel build (2.6.33 x86_64_defconfig) on a Intel Core 2 @ > 1.2GHz: > > <before> > - root cgroup: 11m51.983s > - child cgroup: 11m56.596s > > <after> > - root cgroup: 11m51.742s > - child cgroup: 12m5.016s > > In the previous version of this patchset, using the "complex" locking scheme > with the _locked and _unlocked version of mem_cgroup_update_page_stat(), the > child cgroup required 11m57.896s and 12m9.920s with lock_page_cgroup()+irq_disabled. > > With this version there's no overhead for the root cgroup (the small difference > is in error range). I expected to see less overhead for the child cgroup, I'll > do more testing and try to figure better what's happening. > > In the while, it would be great if someone could perform some tests on a larger > system... unfortunately at the moment I don't have a big system available for > this kind of tests... > > Thanks, > -Andrea > > Documentation/cgroups/memory.txt | 36 +++ > fs/nfs/write.c | 4 + > include/linux/memcontrol.h | 87 ++++++- > include/linux/page_cgroup.h | 35 +++ > include/linux/writeback.h | 2 - > mm/filemap.c | 1 + > mm/memcontrol.c | 542 +++++++++++++++++++++++++++++++++++--- > mm/page-writeback.c | 215 ++++++++++------ > mm/rmap.c | 4 +- > mm/truncate.c | 1 + > 10 files changed, 806 insertions(+), 121 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: Andrea Righi <arighi@develer.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>, Balbir Singh <balbir@linux.vnet.ibm.com>, Peter Zijlstra <peterz@infradead.org>, Trond Myklebust <trond.myklebust@fys.uio.no>, Suleiman Souhlal <suleiman@google.com>, Greg Thelen <gthelen@google.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, Andrew Morton <akpm@linux-foundation.org>, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v7) Date: Mon, 15 Mar 2010 13:12:09 -0400 [thread overview] Message-ID: <20100315171209.GI21127@redhat.com> (raw) In-Reply-To: <1268609202-15581-1-git-send-email-arighi@develer.com> On Mon, Mar 15, 2010 at 12:26:37AM +0100, Andrea Righi wrote: > Control the maximum amount of dirty pages a cgroup can have at any given time. > > Per cgroup dirty limit is like fixing the max amount of dirty (hard to reclaim) > page cache used by any cgroup. So, in case of multiple cgroup writers, they > will not be able to consume more than their designated share of dirty pages and > will be forced to perform write-out if they cross that limit. > For me even with this version I see that group with 100M limit is getting much more BW. root cgroup ========== #time dd if=/dev/zero of=/root/zerofile bs=4K count=1M 4294967296 bytes (4.3 GB) copied, 55.7979 s, 77.0 MB/s real 0m56.209s test1 cgroup with memory limit of 100M ====================================== # time dd if=/dev/zero of=/root/zerofile1 bs=4K count=1M 4294967296 bytes (4.3 GB) copied, 20.9252 s, 205 MB/s real 0m21.096s Note, these two jobs are not running in parallel. These are running one after the other. Vivek > The overall design is the following: > > - account dirty pages per cgroup > - limit the number of dirty pages via memory.dirty_ratio / memory.dirty_bytes > and memory.dirty_background_ratio / memory.dirty_background_bytes in > cgroupfs > - start to write-out (background or actively) when the cgroup limits are > exceeded > > This feature is supposed to be strictly connected to any underlying IO > controller implementation, so we can stop increasing dirty pages in VM layer > and enforce a write-out before any cgroup will consume the global amount of > dirty pages defined by the /proc/sys/vm/dirty_ratio|dirty_bytes and > /proc/sys/vm/dirty_background_ratio|dirty_background_bytes limits. > > Changelog (v6 -> v7) > ~~~~~~~~~~~~~~~~~~~~~~ > * introduce trylock_page_cgroup() to guarantee that lock_page_cgroup() > is never called under tree_lock (no strict accounting, but better overall > performance) > * do not account file cache statistics for the root cgroup (zero > overhead for the root cgroup) > * fix: evaluate cgroup free pages as at the minimum free pages of all > its parents > > Results > ~~~~~~~ > The testcase is a kernel build (2.6.33 x86_64_defconfig) on a Intel Core 2 @ > 1.2GHz: > > <before> > - root cgroup: 11m51.983s > - child cgroup: 11m56.596s > > <after> > - root cgroup: 11m51.742s > - child cgroup: 12m5.016s > > In the previous version of this patchset, using the "complex" locking scheme > with the _locked and _unlocked version of mem_cgroup_update_page_stat(), the > child cgroup required 11m57.896s and 12m9.920s with lock_page_cgroup()+irq_disabled. > > With this version there's no overhead for the root cgroup (the small difference > is in error range). I expected to see less overhead for the child cgroup, I'll > do more testing and try to figure better what's happening. > > In the while, it would be great if someone could perform some tests on a larger > system... unfortunately at the moment I don't have a big system available for > this kind of tests... > > Thanks, > -Andrea > > Documentation/cgroups/memory.txt | 36 +++ > fs/nfs/write.c | 4 + > include/linux/memcontrol.h | 87 ++++++- > include/linux/page_cgroup.h | 35 +++ > include/linux/writeback.h | 2 - > mm/filemap.c | 1 + > mm/memcontrol.c | 542 +++++++++++++++++++++++++++++++++++--- > mm/page-writeback.c | 215 ++++++++++------ > mm/rmap.c | 4 +- > mm/truncate.c | 1 + > 10 files changed, 806 insertions(+), 121 deletions(-) -- 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/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-03-15 17:14 UTC|newest] Thread overview: 204+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-03-14 23:26 [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v7) Andrea Righi 2010-03-14 23:26 ` Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 1/5] memcg: disable irq at page cgroup lock Andrea Righi 2010-03-14 23:26 ` Andrea Righi 2010-03-15 0:06 ` KAMEZAWA Hiroyuki 2010-03-15 0:06 ` KAMEZAWA Hiroyuki 2010-03-15 10:00 ` Andrea Righi 2010-03-15 10:00 ` Andrea Righi [not found] ` <20100315090638.ee416d93.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-15 10:00 ` Andrea Righi [not found] ` <1268609202-15581-2-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org> 2010-03-15 0:06 ` KAMEZAWA Hiroyuki 2010-03-17 7:04 ` Balbir Singh 2010-03-17 11:58 ` Balbir Singh 2010-03-17 7:04 ` Balbir Singh 2010-03-17 7:04 ` Balbir Singh 2010-03-17 11:58 ` Balbir Singh 2010-03-17 11:58 ` Balbir Singh [not found] ` <20100317115855.GS18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-17 23:54 ` KAMEZAWA Hiroyuki 2010-03-17 23:54 ` KAMEZAWA Hiroyuki 2010-03-17 23:54 ` KAMEZAWA Hiroyuki [not found] ` <20100318085411.834e1e46.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-18 0:45 ` KAMEZAWA Hiroyuki 2010-03-18 4:19 ` Balbir Singh 2010-03-18 0:45 ` KAMEZAWA Hiroyuki 2010-03-18 0:45 ` KAMEZAWA Hiroyuki [not found] ` <20100318094519.cd1eed72.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-18 2:16 ` Daisuke Nishimura 2010-03-18 2:16 ` Daisuke Nishimura 2010-03-18 2:16 ` Daisuke Nishimura 2010-03-18 2:58 ` KAMEZAWA Hiroyuki 2010-03-18 2:58 ` KAMEZAWA Hiroyuki [not found] ` <20100318111653.92f899e6.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org> 2010-03-18 2:58 ` KAMEZAWA Hiroyuki 2010-03-18 5:12 ` Balbir Singh 2010-03-18 5:12 ` Balbir Singh 2010-03-18 5:12 ` Balbir Singh 2010-03-18 4:19 ` Balbir Singh 2010-03-18 4:19 ` Balbir Singh 2010-03-18 4:21 ` KAMEZAWA Hiroyuki 2010-03-18 4:21 ` KAMEZAWA Hiroyuki 2010-03-18 6:25 ` Balbir Singh 2010-03-18 6:25 ` Balbir Singh [not found] ` <20100318132114.d5680e1e.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-18 6:25 ` Balbir Singh 2010-03-18 4:35 ` KAMEZAWA Hiroyuki 2010-03-18 4:35 ` KAMEZAWA Hiroyuki 2010-03-18 16:28 ` Balbir Singh 2010-03-18 16:28 ` Balbir Singh [not found] ` <20100318162855.GG18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-19 1:23 ` KAMEZAWA Hiroyuki 2010-03-19 1:23 ` KAMEZAWA Hiroyuki 2010-03-19 1:23 ` KAMEZAWA Hiroyuki 2010-03-19 2:40 ` Balbir Singh 2010-03-19 2:40 ` Balbir Singh [not found] ` <20100319024039.GH18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-19 3:00 ` KAMEZAWA Hiroyuki 2010-03-19 3:00 ` KAMEZAWA Hiroyuki 2010-03-19 3:00 ` KAMEZAWA Hiroyuki [not found] ` <xr93hbnepmj6.fsf@ninji.mtv.corp.google.com> 2010-04-14 6:55 ` Greg Thelen 2010-04-14 6:55 ` Greg Thelen 2010-04-14 9:29 ` KAMEZAWA Hiroyuki 2010-04-14 9:29 ` KAMEZAWA Hiroyuki 2010-04-14 14:04 ` Vivek Goyal 2010-04-14 14:04 ` Vivek Goyal [not found] ` <20100414140430.GB13535-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2010-04-14 19:31 ` Greg Thelen 2010-04-15 0:14 ` KAMEZAWA Hiroyuki 2010-04-14 19:31 ` Greg Thelen 2010-04-14 19:31 ` Greg Thelen 2010-04-15 0:14 ` KAMEZAWA Hiroyuki 2010-04-15 0:14 ` KAMEZAWA Hiroyuki [not found] ` <20100414182904.2f72a63d.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-04-14 14:04 ` Vivek Goyal 2010-04-14 16:22 ` Greg Thelen 2010-04-14 16:22 ` Greg Thelen 2010-04-14 16:22 ` Greg Thelen 2010-04-15 0:22 ` KAMEZAWA Hiroyuki 2010-04-15 0:22 ` KAMEZAWA Hiroyuki [not found] ` <p2k49b004811004140922v8b6c4c57j2dd435261ff2dd43-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-04-15 0:22 ` KAMEZAWA Hiroyuki 2010-04-14 14:05 ` Vivek Goyal 2010-04-14 14:05 ` Vivek Goyal 2010-04-14 20:14 ` Greg Thelen 2010-04-14 20:14 ` Greg Thelen [not found] ` <xr9339yxyepc.fsf-Pk7ff2FLCuk9fRMx9H/SexPsWskHk0ljAL8bYrjMMd8@public.gmane.org> 2010-04-15 2:40 ` Daisuke Nishimura 2010-04-15 2:40 ` Daisuke Nishimura 2010-04-15 2:40 ` Daisuke Nishimura 2010-04-15 4:48 ` Greg Thelen 2010-04-15 4:48 ` Greg Thelen 2010-04-15 6:21 ` Daisuke Nishimura 2010-04-15 6:21 ` Daisuke Nishimura 2010-04-15 6:38 ` Greg Thelen 2010-04-15 6:38 ` Greg Thelen [not found] ` <20100415152104.62593f37.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org> 2010-04-15 6:38 ` Greg Thelen 2010-04-15 6:54 ` KAMEZAWA Hiroyuki 2010-04-15 6:54 ` KAMEZAWA Hiroyuki 2010-04-15 6:54 ` KAMEZAWA Hiroyuki 2010-04-23 20:17 ` Greg Thelen 2010-04-23 20:17 ` Greg Thelen 2010-04-23 20:54 ` Peter Zijlstra 2010-04-23 20:54 ` Peter Zijlstra 2010-04-24 15:53 ` Greg Thelen 2010-04-24 15:53 ` Greg Thelen 2010-04-24 15:53 ` Greg Thelen [not found] ` <xr93k4rxx6sd.fsf-Pk7ff2FLCuk9fRMx9H/SexPsWskHk0ljAL8bYrjMMd8@public.gmane.org> 2010-04-23 20:54 ` Peter Zijlstra 2010-04-23 20:57 ` Peter Zijlstra 2010-04-23 21:19 ` Peter Zijlstra 2010-04-24 2:19 ` KAMEZAWA Hiroyuki 2010-04-23 20:57 ` Peter Zijlstra 2010-04-23 20:57 ` Peter Zijlstra 2010-04-24 2:22 ` KAMEZAWA Hiroyuki 2010-04-24 2:22 ` KAMEZAWA Hiroyuki 2010-04-24 2:22 ` KAMEZAWA Hiroyuki 2010-04-23 21:19 ` Peter Zijlstra 2010-04-23 21:19 ` Peter Zijlstra 2010-04-24 2:19 ` KAMEZAWA Hiroyuki 2010-04-24 2:19 ` KAMEZAWA Hiroyuki 2010-04-23 20:17 ` Greg Thelen [not found] ` <g2u49b004811004142148i3db9fefaje1f20760426e0c7e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-04-15 6:21 ` Daisuke Nishimura [not found] ` <20100415114022.ef01b704.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org> 2010-04-15 4:48 ` Greg Thelen [not found] ` <20100414140523.GC13535-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2010-04-14 20:14 ` Greg Thelen 2010-04-14 14:44 ` Balbir Singh 2010-04-14 14:44 ` Balbir Singh [not found] ` <xr931veiplpr.fsf-Pk7ff2FLCuk9fRMx9H/SexPsWskHk0ljAL8bYrjMMd8@public.gmane.org> 2010-04-14 9:29 ` KAMEZAWA Hiroyuki 2010-04-14 14:05 ` Vivek Goyal 2010-04-14 14:44 ` Balbir Singh [not found] ` <xr93hbnepmj6.fsf-Pk7ff2FLCuk9fRMx9H/SexPsWskHk0ljAL8bYrjMMd8@public.gmane.org> 2010-04-14 6:55 ` Greg Thelen [not found] ` <20100319102332.f1d81c8d.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-19 2:40 ` Balbir Singh [not found] ` <20100318133527.420b2f25.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-18 16:28 ` Balbir Singh [not found] ` <20100318041944.GA18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-18 4:21 ` KAMEZAWA Hiroyuki 2010-03-18 4:35 ` KAMEZAWA Hiroyuki 2010-03-14 23:26 ` [PATCH -mmotm 2/5] memcg: dirty memory documentation Andrea Righi 2010-03-14 23:26 ` Andrea Righi [not found] ` <1268609202-15581-3-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org> 2010-03-16 7:41 ` Daisuke Nishimura 2010-03-16 7:41 ` Daisuke Nishimura 2010-03-16 7:41 ` Daisuke Nishimura [not found] ` <20100316164121.024e35d8.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org> 2010-03-17 17:48 ` Greg Thelen 2010-03-17 22:43 ` Andrea Righi 2010-03-17 17:48 ` Greg Thelen 2010-03-17 17:48 ` Greg Thelen [not found] ` <49b004811003171048h5f27405oe6ea39a103bc4ee3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-03-17 19:02 ` Balbir Singh 2010-03-17 19:02 ` Balbir Singh 2010-03-17 19:02 ` Balbir Singh 2010-03-17 22:43 ` Andrea Righi 2010-03-17 22:43 ` Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 3/5] page_cgroup: introduce file cache flags Andrea Righi 2010-03-14 23:26 ` Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 4/5] memcg: dirty pages accounting and limiting infrastructure Andrea Righi 2010-03-14 23:26 ` Andrea Righi 2010-03-15 2:26 ` KAMEZAWA Hiroyuki 2010-03-15 2:26 ` KAMEZAWA Hiroyuki [not found] ` <1268609202-15581-5-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org> 2010-03-15 2:26 ` KAMEZAWA Hiroyuki 2010-03-16 2:32 ` Daisuke Nishimura 2010-03-18 6:48 ` Greg Thelen 2010-03-16 2:32 ` Daisuke Nishimura 2010-03-16 2:32 ` Daisuke Nishimura 2010-03-16 14:11 ` Vivek Goyal 2010-03-16 14:11 ` Vivek Goyal 2010-03-16 15:09 ` Daisuke Nishimura 2010-03-16 15:09 ` Daisuke Nishimura [not found] ` <20100316141150.GC9144-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2010-03-16 15:09 ` Daisuke Nishimura 2010-03-17 22:37 ` Andrea Righi 2010-03-17 22:37 ` Andrea Righi 2010-03-17 22:37 ` Andrea Righi [not found] ` <20100316113238.f7d74848.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org> 2010-03-16 14:11 ` Vivek Goyal 2010-03-17 22:52 ` Andrea Righi 2010-03-17 22:52 ` Andrea Righi 2010-03-17 22:52 ` Andrea Righi 2010-03-18 6:48 ` Greg Thelen 2010-03-18 6:48 ` Greg Thelen 2010-03-14 23:26 ` [PATCH -mmotm 5/5] memcg: dirty pages instrumentation Andrea Righi 2010-03-14 23:26 ` Andrea Righi [not found] ` <1268609202-15581-6-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org> 2010-03-15 2:31 ` KAMEZAWA Hiroyuki 2010-03-15 2:31 ` KAMEZAWA Hiroyuki 2010-03-15 2:31 ` KAMEZAWA Hiroyuki 2010-03-15 2:36 ` [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v7) KAMEZAWA Hiroyuki 2010-03-15 2:36 ` KAMEZAWA Hiroyuki 2010-03-15 10:02 ` Andrea Righi 2010-03-15 10:02 ` Andrea Righi [not found] ` <20100315113612.8411d92d.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2010-03-15 10:02 ` Andrea Righi [not found] ` <1268609202-15581-1-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org> 2010-03-14 23:26 ` [PATCH -mmotm 1/5] memcg: disable irq at page cgroup lock Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 2/5] memcg: dirty memory documentation Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 3/5] page_cgroup: introduce file cache flags Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 4/5] memcg: dirty pages accounting and limiting infrastructure Andrea Righi 2010-03-14 23:26 ` [PATCH -mmotm 5/5] memcg: dirty pages instrumentation Andrea Righi 2010-03-15 2:36 ` [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v7) KAMEZAWA Hiroyuki 2010-03-15 17:12 ` Vivek Goyal 2010-03-17 6:44 ` Balbir Singh 2010-03-15 17:12 ` Vivek Goyal [this message] 2010-03-15 17:12 ` Vivek Goyal [not found] ` <20100315171209.GI21127-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2010-03-15 17:19 ` Vivek Goyal 2010-03-15 17:19 ` Vivek Goyal 2010-03-15 17:19 ` Vivek Goyal 2010-03-17 11:54 ` Balbir Singh 2010-03-17 11:54 ` Balbir Singh 2010-03-17 13:34 ` Vivek Goyal 2010-03-17 13:34 ` Vivek Goyal 2010-03-17 18:53 ` Balbir Singh 2010-03-17 18:53 ` Balbir Singh 2010-03-17 19:15 ` Vivek Goyal 2010-03-17 19:15 ` Vivek Goyal [not found] ` <20100317185327.GV18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-17 19:15 ` Vivek Goyal 2010-03-17 19:17 ` Balbir Singh 2010-03-17 19:17 ` Balbir Singh [not found] ` <20100317191743.GY18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-17 19:48 ` Vivek Goyal 2010-03-17 19:48 ` Vivek Goyal 2010-03-17 19:48 ` Vivek Goyal [not found] ` <20100317133407.GA9198-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2010-03-17 18:53 ` Balbir Singh 2010-03-17 19:17 ` Balbir Singh [not found] ` <20100317115427.GR18054-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 2010-03-17 13:34 ` Vivek Goyal [not found] ` <20100315171921.GJ21127-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2010-03-17 11:54 ` Balbir Singh 2010-03-17 6:44 ` Balbir Singh 2010-03-17 6:44 ` Balbir Singh -- strict thread matches above, loose matches on Subject: below -- 2010-03-14 23:26 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=20100315171209.GI21127@redhat.com \ --to=vgoyal@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=arighi@develer.com \ --cc=balbir@linux.vnet.ibm.com \ --cc=containers@lists.linux-foundation.org \ --cc=gthelen@google.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=nishimura@mxp.nes.nec.co.jp \ --cc=peterz@infradead.org \ --cc=suleiman@google.com \ --cc=trond.myklebust@fys.uio.no \ /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.