[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Mon, Mar 15, 2010 at 10:38:41AM -0400, Vivek Goyal wrote: > > > > > > bdi_thres ~= per_memory_cgroup_dirty * bdi_fraction > > > > > > But bdi_nr_reclaimable and bdi_nr_writeback stats are still global. > > > > > Why bdi_thresh of ROOT cgroup doesn't depend on global number ? > > > > I think

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Fri, Mar 12, 2010 at 10:14:11AM +0900, Daisuke Nishimura wrote: > On Thu, 11 Mar 2010 18:42:44 +0900, KAMEZAWA Hiroyuki > wrote: > > On Thu, 11 Mar 2010 18:25:00 +0900 > > KAMEZAWA Hiroyuki wrote: > > > Then, it's not problem that check pc->mem_cgroup is root cgroup or not > > > without spinl

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Fri, Mar 12, 2010 at 08:52:44AM +0900, KAMEZAWA Hiroyuki wrote: > On Fri, 12 Mar 2010 00:27:09 +0100 > Andrea Righi wrote: > > > On Thu, Mar 11, 2010 at 10:03:07AM -0500, Vivek Goyal wrote: > > > > I am still setting up the system to test whether we see any speedup in > > > writeout of large

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Fri, Mar 12, 2010 at 09:03:26AM +0900, KAMEZAWA Hiroyuki wrote: > On Fri, 12 Mar 2010 00:59:22 +0100 > Andrea Righi wrote: > > > On Thu, Mar 11, 2010 at 01:07:53PM -0500, Vivek Goyal wrote: > > > On Wed, Mar 10, 2010 at 12:00:31AM +0100, Andrea Righi wrote: > > > mmmh.. strange, on my side I

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Fri, Mar 12, 2010 at 08:42:30AM +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 11 Mar 2010 10:03:07 -0500 > Vivek Goyal wrote: > > > On Thu, Mar 11, 2010 at 06:25:00PM +0900, KAMEZAWA Hiroyuki wrote: > > > On Thu, 11 Mar 2010 10:14:25 +0100 > > > Peter Zijlstra wrote: > > > > > > > On Thu, 2010-0

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Thu, Mar 11, 2010 at 01:07:53PM -0500, Vivek Goyal wrote: > On Wed, Mar 10, 2010 at 12:00:31AM +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 > > r

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Thu, Mar 11, 2010 at 10:03:07AM -0500, Vivek Goyal wrote: > On Thu, Mar 11, 2010 at 06:25:00PM +0900, KAMEZAWA Hiroyuki wrote: > > On Thu, 11 Mar 2010 10:14:25 +0100 > > Peter Zijlstra wrote: > > > > > On Thu, 2010-03-11 at 10:17 +0900, KAMEZAWA Hiroyuki wrote: > > > > On Thu, 11 Mar 2010 09:3

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Thu, Mar 11, 2010 at 06:42:44PM +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 11 Mar 2010 18:25:00 +0900 > KAMEZAWA Hiroyuki wrote: > > Then, it's not problem that check pc->mem_cgroup is root cgroup or not > > without spinlock. > > == > > void mem_cgroup_update_stat(struct page *page, int idx, boo

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-30 Thread Andrea Righi
On Thu, Mar 11, 2010 at 09:39:13AM +0900, KAMEZAWA Hiroyuki wrote: > On Wed, 10 Mar 2010 00:00:31 +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

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-15 Thread Vivek Goyal
On Fri, Mar 12, 2010 at 11:24:33AM +0900, KAMEZAWA Hiroyuki wrote: > On Fri, 12 Mar 2010 10:14:11 +0900 > Daisuke Nishimura wrote: > > > On Thu, 11 Mar 2010 18:42:44 +0900, KAMEZAWA Hiroyuki > > wrote: > > > On Thu, 11 Mar 2010 18:25:00 +0900 > > > KAMEZAWA Hiroyuki wrote: > > > > Then, it's n

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-15 Thread Vivek Goyal
On Fri, Mar 12, 2010 at 12:59:22AM +0100, Andrea Righi wrote: > On Thu, Mar 11, 2010 at 01:07:53PM -0500, Vivek Goyal wrote: > > On Wed, Mar 10, 2010 at 12:00:31AM +0100, Andrea Righi wrote: > > > Control the maximum amount of dirty pages a cgroup can have at any given > > > time. > > > > > > Per

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-15 Thread Vivek Goyal
On Fri, Mar 12, 2010 at 08:42:30AM +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 11 Mar 2010 10:03:07 -0500 > Vivek Goyal wrote: > > > On Thu, Mar 11, 2010 at 06:25:00PM +0900, KAMEZAWA Hiroyuki wrote: > > > On Thu, 11 Mar 2010 10:14:25 +0100 > > > Peter Zijlstra wrote: > > > > > > > On Thu, 2010-0

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-15 Thread Vivek Goyal
On Fri, Mar 12, 2010 at 12:27:09AM +0100, Andrea Righi wrote: > On Thu, Mar 11, 2010 at 10:03:07AM -0500, Vivek Goyal wrote: > > On Thu, Mar 11, 2010 at 06:25:00PM +0900, KAMEZAWA Hiroyuki wrote: > > > On Thu, 11 Mar 2010 10:14:25 +0100 > > > Peter Zijlstra wrote: > > > > > > > On Thu, 2010-03-11

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread KAMEZAWA Hiroyuki
On Fri, 12 Mar 2010 10:14:11 +0900 Daisuke Nishimura wrote: > On Thu, 11 Mar 2010 18:42:44 +0900, KAMEZAWA Hiroyuki > wrote: > > On Thu, 11 Mar 2010 18:25:00 +0900 > > KAMEZAWA Hiroyuki wrote: > > > Then, it's not problem that check pc->mem_cgroup is root cgroup or not > > > without spinlock.

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread Daisuke Nishimura
On Thu, 11 Mar 2010 18:42:44 +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 11 Mar 2010 18:25:00 +0900 > KAMEZAWA Hiroyuki wrote: > > Then, it's not problem that check pc->mem_cgroup is root cgroup or not > > without spinlock. > > == > > void mem_cgroup_update_stat(struct page *page, int idx, bool ch

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread KAMEZAWA Hiroyuki
On Fri, 12 Mar 2010 00:59:22 +0100 Andrea Righi wrote: > On Thu, Mar 11, 2010 at 01:07:53PM -0500, Vivek Goyal wrote: > > On Wed, Mar 10, 2010 at 12:00:31AM +0100, Andrea Righi wrote: > mmmh.. strange, on my side I get something as expected: > > > $ dd if=/dev/zero of=test bs=1M count=500 > 50

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread KAMEZAWA Hiroyuki
On Fri, 12 Mar 2010 00:27:09 +0100 Andrea Righi wrote: > On Thu, Mar 11, 2010 at 10:03:07AM -0500, Vivek Goyal wrote: > > I am still setting up the system to test whether we see any speedup in > > writeout of large files with-in a memory cgroup with small memory limits. > > I am assuming that we

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread KAMEZAWA Hiroyuki
On Thu, 11 Mar 2010 10:03:07 -0500 Vivek Goyal wrote: > On Thu, Mar 11, 2010 at 06:25:00PM +0900, KAMEZAWA Hiroyuki wrote: > > On Thu, 11 Mar 2010 10:14:25 +0100 > > Peter Zijlstra wrote: > > > > > On Thu, 2010-03-11 at 10:17 +0900, KAMEZAWA Hiroyuki wrote: > > > > On Thu, 11 Mar 2010 09:39:13

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread Vivek Goyal
On Wed, Mar 10, 2010 at 12:00:31AM +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 writ

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread Vivek Goyal
On Thu, Mar 11, 2010 at 06:25:00PM +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 11 Mar 2010 10:14:25 +0100 > Peter Zijlstra wrote: > > > On Thu, 2010-03-11 at 10:17 +0900, KAMEZAWA Hiroyuki wrote: > > > On Thu, 11 Mar 2010 09:39:13 +0900 > > > KAMEZAWA Hiroyuki wrote: > > > > > The performance over

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread KAMEZAWA Hiroyuki
On Thu, 11 Mar 2010 18:25:00 +0900 KAMEZAWA Hiroyuki wrote: > Then, it's not problem that check pc->mem_cgroup is root cgroup or not > without spinlock. > == > void mem_cgroup_update_stat(struct page *page, int idx, bool charge) > { > pc = lookup_page_cgroup(page); > if (unlikely(!pc)

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread KAMEZAWA Hiroyuki
On Thu, 11 Mar 2010 10:14:25 +0100 Peter Zijlstra wrote: > On Thu, 2010-03-11 at 10:17 +0900, KAMEZAWA Hiroyuki wrote: > > On Thu, 11 Mar 2010 09:39:13 +0900 > > KAMEZAWA Hiroyuki wrote: > > > > The performance overhead is not so huge in both solutions, but the > > > > impact on > > > > perform

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-11 Thread Peter Zijlstra
On Thu, 2010-03-11 at 10:17 +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 11 Mar 2010 09:39:13 +0900 > KAMEZAWA Hiroyuki wrote: > > > The performance overhead is not so huge in both solutions, but the impact > > > on > > > performance is even more reduced using a complicated solution... > > > > > >

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-10 Thread KAMEZAWA Hiroyuki
On Thu, 11 Mar 2010 09:39:13 +0900 KAMEZAWA Hiroyuki wrote: > > The performance overhead is not so huge in both solutions, but the impact on > > performance is even more reduced using a complicated solution... > > > > Maybe we can go ahead with the simplest implementation for now and start to > >

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-10 Thread KAMEZAWA Hiroyuki
On Wed, 10 Mar 2010 00:00:31 +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,

[Devel] Re: [PATCH -mmotm 0/5] memcg: per cgroup dirty limit (v6)

2010-03-09 Thread Balbir Singh
* Andrea Righi [2010-03-10 00:00:31]: > 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 b