All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@develer.com>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Suleiman Souhlal <suleiman@google.com>,
	Greg Thelen <gthelen@google.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	"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 2/3] memcg: dirty pages accounting and limiting infrastructure
Date: Tue, 2 Mar 2010 22:50:16 +0100	[thread overview]
Message-ID: <20100302215016.GA2369@linux> (raw)
In-Reply-To: <20100302130223.GF3212@balbir.in.ibm.com>

On Tue, Mar 02, 2010 at 06:32:24PM +0530, Balbir Singh wrote:

[snip]

> > +extern long mem_cgroup_dirty_ratio(void);
> > +extern unsigned long mem_cgroup_dirty_bytes(void);
> > +extern long mem_cgroup_dirty_background_ratio(void);
> > +extern unsigned long mem_cgroup_dirty_background_bytes(void);
> > +
> > +extern s64 mem_cgroup_page_stat(enum mem_cgroup_page_stat_item item);
> > +
> 
> Docstyle comments for each function would be appreciated

OK.

> >  /*
> >   * The memory controller data structure. The memory controller controls both
> >   * page cache and RSS per cgroup. We would eventually like to provide
> > @@ -205,6 +199,9 @@ struct mem_cgroup {
> > 
> >  	unsigned int	swappiness;
> > 
> > +	/* control memory cgroup dirty pages */
> > +	unsigned long dirty_param[MEM_CGROUP_DIRTY_NPARAMS];
> > +
> 
> Could you mention what protects this field, is it the reclaim_lock?

Yes, it is.

Actually, we could avoid the lock completely for dirty_param[], using a
validation routine to check for incoherencies after any read with
get_dirty_param(), and retry if the validation fails. In practice, the
same approach we're using to read global vm_dirty_ratio, vm_dirty_bytes,
etc...

Considering that those values are rarely written and read often we can
protect them in a RCU way.


> BTW, is unsigned long sufficient to represent dirty_param(s)?

Yes, I think. It's the same type used for the equivalent global values.

> 
> >  	/* set when res.limit == memsw.limit */
> >  	bool		memsw_is_minimum;
> > 
> > @@ -1021,6 +1018,164 @@ static unsigned int get_swappiness(struct mem_cgroup *memcg)
> >  	return swappiness;
> >  }
> > 
> > +static unsigned long get_dirty_param(struct mem_cgroup *memcg,
> > +			enum mem_cgroup_dirty_param idx)
> > +{
> > +	unsigned long ret;
> > +
> > +	VM_BUG_ON(idx >= MEM_CGROUP_DIRTY_NPARAMS);
> > +	spin_lock(&memcg->reclaim_param_lock);
> > +	ret = memcg->dirty_param[idx];
> > +	spin_unlock(&memcg->reclaim_param_lock);
> 
> Do we need a spinlock if we protect it using RCU? Is precise data very
> important?

See above.

> > +unsigned long mem_cgroup_dirty_background_bytes(void)
> > +{
> > +	struct mem_cgroup *memcg;
> > +	unsigned long ret = dirty_background_bytes;
> > +
> > +	if (mem_cgroup_disabled())
> > +		return ret;
> > +	rcu_read_lock();
> > +	memcg = mem_cgroup_from_task(current);
> > +	if (likely(memcg))
> > +		ret = get_dirty_param(memcg, MEM_CGROUP_DIRTY_BACKGROUND_BYTES);
> > +	rcu_read_unlock();
> > +
> > +	return ret;
> > +}
> > +
> > +static inline bool mem_cgroup_can_swap(struct mem_cgroup *memcg)
> > +{
> > +	return do_swap_account ?
> > +			res_counter_read_u64(&memcg->memsw, RES_LIMIT) :
> 
> Shouldn't you do a res_counter_read_u64(...) > 0 for readability?

OK.

> What happens if memcg->res, RES_LIMIT == memcg->memsw, RES_LIMIT?

OK, we should also check memcg->memsw_is_minimum.

> >  static struct cgroup_subsys_state * __ref
> >  mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
> >  {
> > @@ -3776,8 +4031,37 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
> >  	mem->last_scanned_child = 0;
> >  	spin_lock_init(&mem->reclaim_param_lock);
> > 
> > -	if (parent)
> > +	if (parent) {
> >  		mem->swappiness = get_swappiness(parent);
> > +
> > +		spin_lock(&parent->reclaim_param_lock);
> > +		copy_dirty_params(mem, parent);
> > +		spin_unlock(&parent->reclaim_param_lock);
> > +	} else {
> > +		/*
> > +		 * XXX: should we need a lock here? we could switch from
> > +		 * vm_dirty_ratio to vm_dirty_bytes or vice versa but we're not
> > +		 * reading them atomically. The same for dirty_background_ratio
> > +		 * and dirty_background_bytes.
> > +		 *
> > +		 * For now, try to read them speculatively and retry if a
> > +		 * "conflict" is detected.a
> 
> The do while loop is subtle, can we add a validate check,share it with
> the write routine and retry if validation fails?

Agreed.

> 
> > +		 */
> > +		do {
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_RATIO] =
> > +						vm_dirty_ratio;
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BYTES] =
> > +						vm_dirty_bytes;
> > +		} while (mem->dirty_param[MEM_CGROUP_DIRTY_RATIO] &&
> > +			 mem->dirty_param[MEM_CGROUP_DIRTY_BYTES]);
> > +		do {
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_RATIO] =
> > +						dirty_background_ratio;
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_BYTES] =
> > +						dirty_background_bytes;
> > +		} while (mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_RATIO] &&
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_BYTES]);
> > +	}
> >  	atomic_set(&mem->refcnt, 1);
> >  	mem->move_charge_at_immigrate = 0;
> >  	mutex_init(&mem->thresholds_lock);

Many thanks for reviewing,
-Andrea

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Righi <arighi@develer.com>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Suleiman Souhlal <suleiman@google.com>,
	Greg Thelen <gthelen@google.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	"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 2/3] memcg: dirty pages accounting and limiting infrastructure
Date: Tue, 2 Mar 2010 22:50:16 +0100	[thread overview]
Message-ID: <20100302215016.GA2369@linux> (raw)
In-Reply-To: <20100302130223.GF3212@balbir.in.ibm.com>

On Tue, Mar 02, 2010 at 06:32:24PM +0530, Balbir Singh wrote:

[snip]

> > +extern long mem_cgroup_dirty_ratio(void);
> > +extern unsigned long mem_cgroup_dirty_bytes(void);
> > +extern long mem_cgroup_dirty_background_ratio(void);
> > +extern unsigned long mem_cgroup_dirty_background_bytes(void);
> > +
> > +extern s64 mem_cgroup_page_stat(enum mem_cgroup_page_stat_item item);
> > +
> 
> Docstyle comments for each function would be appreciated

OK.

> >  /*
> >   * The memory controller data structure. The memory controller controls both
> >   * page cache and RSS per cgroup. We would eventually like to provide
> > @@ -205,6 +199,9 @@ struct mem_cgroup {
> > 
> >  	unsigned int	swappiness;
> > 
> > +	/* control memory cgroup dirty pages */
> > +	unsigned long dirty_param[MEM_CGROUP_DIRTY_NPARAMS];
> > +
> 
> Could you mention what protects this field, is it the reclaim_lock?

Yes, it is.

Actually, we could avoid the lock completely for dirty_param[], using a
validation routine to check for incoherencies after any read with
get_dirty_param(), and retry if the validation fails. In practice, the
same approach we're using to read global vm_dirty_ratio, vm_dirty_bytes,
etc...

Considering that those values are rarely written and read often we can
protect them in a RCU way.


> BTW, is unsigned long sufficient to represent dirty_param(s)?

Yes, I think. It's the same type used for the equivalent global values.

> 
> >  	/* set when res.limit == memsw.limit */
> >  	bool		memsw_is_minimum;
> > 
> > @@ -1021,6 +1018,164 @@ static unsigned int get_swappiness(struct mem_cgroup *memcg)
> >  	return swappiness;
> >  }
> > 
> > +static unsigned long get_dirty_param(struct mem_cgroup *memcg,
> > +			enum mem_cgroup_dirty_param idx)
> > +{
> > +	unsigned long ret;
> > +
> > +	VM_BUG_ON(idx >= MEM_CGROUP_DIRTY_NPARAMS);
> > +	spin_lock(&memcg->reclaim_param_lock);
> > +	ret = memcg->dirty_param[idx];
> > +	spin_unlock(&memcg->reclaim_param_lock);
> 
> Do we need a spinlock if we protect it using RCU? Is precise data very
> important?

See above.

> > +unsigned long mem_cgroup_dirty_background_bytes(void)
> > +{
> > +	struct mem_cgroup *memcg;
> > +	unsigned long ret = dirty_background_bytes;
> > +
> > +	if (mem_cgroup_disabled())
> > +		return ret;
> > +	rcu_read_lock();
> > +	memcg = mem_cgroup_from_task(current);
> > +	if (likely(memcg))
> > +		ret = get_dirty_param(memcg, MEM_CGROUP_DIRTY_BACKGROUND_BYTES);
> > +	rcu_read_unlock();
> > +
> > +	return ret;
> > +}
> > +
> > +static inline bool mem_cgroup_can_swap(struct mem_cgroup *memcg)
> > +{
> > +	return do_swap_account ?
> > +			res_counter_read_u64(&memcg->memsw, RES_LIMIT) :
> 
> Shouldn't you do a res_counter_read_u64(...) > 0 for readability?

OK.

> What happens if memcg->res, RES_LIMIT == memcg->memsw, RES_LIMIT?

OK, we should also check memcg->memsw_is_minimum.

> >  static struct cgroup_subsys_state * __ref
> >  mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
> >  {
> > @@ -3776,8 +4031,37 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
> >  	mem->last_scanned_child = 0;
> >  	spin_lock_init(&mem->reclaim_param_lock);
> > 
> > -	if (parent)
> > +	if (parent) {
> >  		mem->swappiness = get_swappiness(parent);
> > +
> > +		spin_lock(&parent->reclaim_param_lock);
> > +		copy_dirty_params(mem, parent);
> > +		spin_unlock(&parent->reclaim_param_lock);
> > +	} else {
> > +		/*
> > +		 * XXX: should we need a lock here? we could switch from
> > +		 * vm_dirty_ratio to vm_dirty_bytes or vice versa but we're not
> > +		 * reading them atomically. The same for dirty_background_ratio
> > +		 * and dirty_background_bytes.
> > +		 *
> > +		 * For now, try to read them speculatively and retry if a
> > +		 * "conflict" is detected.a
> 
> The do while loop is subtle, can we add a validate check,share it with
> the write routine and retry if validation fails?

Agreed.

> 
> > +		 */
> > +		do {
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_RATIO] =
> > +						vm_dirty_ratio;
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BYTES] =
> > +						vm_dirty_bytes;
> > +		} while (mem->dirty_param[MEM_CGROUP_DIRTY_RATIO] &&
> > +			 mem->dirty_param[MEM_CGROUP_DIRTY_BYTES]);
> > +		do {
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_RATIO] =
> > +						dirty_background_ratio;
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_BYTES] =
> > +						dirty_background_bytes;
> > +		} while (mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_RATIO] &&
> > +			mem->dirty_param[MEM_CGROUP_DIRTY_BACKGROUND_BYTES]);
> > +	}
> >  	atomic_set(&mem->refcnt, 1);
> >  	mem->move_charge_at_immigrate = 0;
> >  	mutex_init(&mem->thresholds_lock);

Many thanks for reviewing,
-Andrea

--
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>

  parent reply	other threads:[~2010-03-02 21:50 UTC|newest]

Thread overview: 140+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01 21:23 [PATCH -mmotm 0/3] memcg: per cgroup dirty limit (v3) Andrea Righi
2010-03-01 21:23 ` Andrea Righi
2010-03-01 21:23 ` [PATCH -mmotm 1/3] memcg: dirty memory documentation Andrea Righi
2010-03-01 21:23   ` Andrea Righi
     [not found] ` <1267478620-5276-1-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org>
2010-03-01 21:23   ` Andrea Righi
2010-03-01 21:23   ` [PATCH -mmotm 2/3] memcg: dirty pages accounting and limiting infrastructure Andrea Righi
2010-03-01 21:23   ` [PATCH -mmotm 3/3] memcg: dirty pages instrumentation Andrea Righi
2010-03-01 21:23 ` [PATCH -mmotm 2/3] memcg: dirty pages accounting and limiting infrastructure Andrea Righi
2010-03-01 21:23   ` Andrea Righi
2010-03-02  0:20   ` KAMEZAWA Hiroyuki
2010-03-02  0:20     ` KAMEZAWA Hiroyuki
2010-03-02 10:04   ` Kirill A. Shutemov
2010-03-02 10:04     ` Kirill A. Shutemov
2010-03-02 11:00     ` Andrea Righi
2010-03-02 11:00       ` Andrea Righi
     [not found]     ` <cc557aab1003020204k16038838ta537357aeeb67b11-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-02 11:00       ` Andrea Righi
     [not found]   ` <1267478620-5276-3-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org>
2010-03-02  0:20     ` KAMEZAWA Hiroyuki
2010-03-02 10:04     ` Kirill A. Shutemov
2010-03-02 13:02     ` Balbir Singh
2010-03-02 18:08     ` Greg Thelen
2010-03-02 13:02   ` Balbir Singh
2010-03-02 13:02     ` Balbir Singh
     [not found]     ` <20100302130223.GF3212-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2010-03-02 21:50       ` Andrea Righi
2010-03-02 21:50     ` Andrea Righi [this message]
2010-03-02 21:50       ` Andrea Righi
2010-03-02 18:08   ` Greg Thelen
2010-03-02 18:08     ` Greg Thelen
     [not found]     ` <49b004811003021008t4fae71bbu8d56192e48c32f39-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-02 22:24       ` Andrea Righi
2010-03-02 22:24     ` Andrea Righi
2010-03-02 22:24       ` Andrea Righi
2010-03-01 21:23 ` [PATCH -mmotm 3/3] memcg: dirty pages instrumentation Andrea Righi
2010-03-01 21:23   ` Andrea Righi
2010-03-01 22:02   ` Vivek Goyal
2010-03-01 22:02     ` Vivek Goyal
2010-03-01 22:18     ` Andrea Righi
2010-03-01 22:18       ` Andrea Righi
2010-03-02 15:05       ` Vivek Goyal
2010-03-02 15:05       ` Vivek Goyal
2010-03-02 15:05         ` Vivek Goyal
     [not found]         ` <20100302150529.GA12855-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-03-02 22:22           ` Andrea Righi
2010-03-02 22:22         ` Andrea Righi
2010-03-02 22:22           ` Andrea Righi
2010-03-02 23:59           ` Vivek Goyal
2010-03-02 23:59           ` Vivek Goyal
2010-03-02 23:59             ` Vivek Goyal
2010-03-03 11:47             ` Andrea Righi
2010-03-03 11:47               ` Andrea Righi
2010-03-03 11:56               ` Andrea Righi
2010-03-03 11:56                 ` Andrea Righi
2010-03-03 11:56               ` Andrea Righi
     [not found]             ` <20100302235932.GA3007-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-03-03 11:47               ` Andrea Righi
     [not found]     ` <20100301220208.GH3109-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-03-01 22:18       ` Andrea Righi
2010-03-02  0:23   ` KAMEZAWA Hiroyuki
2010-03-02  0:23     ` KAMEZAWA Hiroyuki
2010-03-02  8:01     ` Andrea Righi
2010-03-02  8:01       ` Andrea Righi
2010-03-02  8:12       ` Daisuke Nishimura
2010-03-02  8:12       ` Daisuke Nishimura
2010-03-02  8:12         ` Daisuke Nishimura
2010-03-02  8:23       ` KAMEZAWA Hiroyuki
2010-03-02  8:23         ` KAMEZAWA Hiroyuki
     [not found]         ` <20100302172316.b959b04c.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2010-03-02 13:50           ` Balbir Singh
2010-03-02 13:50         ` Balbir Singh
2010-03-02 13:50           ` Balbir Singh
     [not found]           ` <20100302135026.GH3212-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2010-03-02 22:18             ` Andrea Righi
2010-03-02 22:18           ` Andrea Righi
2010-03-02 22:18             ` Andrea Righi
2010-03-02 23:21             ` Daisuke Nishimura
2010-03-02 23:21             ` Daisuke Nishimura
2010-03-02 23:21               ` Daisuke Nishimura
2010-03-03 11:48               ` Andrea Righi
2010-03-03 11:48                 ` Andrea Righi
     [not found]               ` <20100303082107.a29562fa.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org>
2010-03-03 11:48                 ` Andrea Righi
2010-03-02  8:23       ` KAMEZAWA Hiroyuki
     [not found]     ` <20100302092309.bff454d7.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2010-03-02  8:01       ` Andrea Righi
2010-03-02 10:11   ` Kirill A. Shutemov
2010-03-02 10:11     ` Kirill A. Shutemov
2010-03-02 11:02     ` Andrea Righi
2010-03-02 11:02       ` Andrea Righi
2010-03-02 11:09       ` Kirill A. Shutemov
2010-03-02 11:09       ` Kirill A. Shutemov
2010-03-02 11:09         ` Kirill A. Shutemov
2010-03-02 11:34         ` Andrea Righi
2010-03-02 11:34           ` Andrea Righi
     [not found]         ` <cc557aab1003020309y37587110i685d0d968bfba9f4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-02 11:34           ` Andrea Righi
     [not found]     ` <cc557aab1003020211h391947f0p3eae04a298127d32-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-02 11:02       ` Andrea Righi
2010-03-02 13:47   ` Balbir Singh
2010-03-02 13:47     ` Balbir Singh
2010-03-02 13:56     ` Kirill A. Shutemov
2010-03-02 13:56       ` Kirill A. Shutemov
     [not found]     ` <20100302134736.GG3212-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2010-03-02 13:56       ` Kirill A. Shutemov
     [not found]   ` <1267478620-5276-4-git-send-email-arighi-vWjgImWzx8FBDgjK7y7TUQ@public.gmane.org>
2010-03-01 22:02     ` Vivek Goyal
2010-03-02  0:23     ` KAMEZAWA Hiroyuki
2010-03-02 10:11     ` Kirill A. Shutemov
2010-03-02 13:47     ` Balbir Singh
2010-03-02 13:48     ` Peter Zijlstra
2010-03-03  2:12     ` Daisuke Nishimura
2010-03-02 13:48   ` Peter Zijlstra
2010-03-02 13:48     ` Peter Zijlstra
2010-03-02 15:26     ` Balbir Singh
2010-03-02 15:26       ` Balbir Singh
2010-03-02 15:26     ` Balbir Singh
2010-03-02 15:49     ` Trond Myklebust
2010-03-02 15:49       ` Trond Myklebust
2010-03-02 15:49     ` Trond Myklebust
2010-03-02 22:14     ` Andrea Righi
2010-03-02 22:14     ` Andrea Righi
2010-03-02 22:14       ` Andrea Righi
2010-03-03 10:07       ` Peter Zijlstra
2010-03-03 10:07       ` Peter Zijlstra
2010-03-03 10:07         ` Peter Zijlstra
2010-03-03 12:05         ` Andrea Righi
2010-03-03 12:05           ` Andrea Righi
2010-03-03 12:05         ` Andrea Righi
2010-03-03  2:12   ` Daisuke Nishimura
2010-03-03  2:12     ` Daisuke Nishimura
2010-03-03  3:29     ` KAMEZAWA Hiroyuki
2010-03-03  3:29       ` KAMEZAWA Hiroyuki
2010-03-03  6:01       ` Daisuke Nishimura
2010-03-03  6:01         ` Daisuke Nishimura
     [not found]         ` <20100303150137.f56d7084.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org>
2010-03-03  6:15           ` KAMEZAWA Hiroyuki
2010-03-03  6:15         ` KAMEZAWA Hiroyuki
2010-03-03  6:15           ` KAMEZAWA Hiroyuki
     [not found]           ` <20100303151549.5d3d686a.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2010-03-03  8:21             ` KAMEZAWA Hiroyuki
2010-03-03  8:21           ` KAMEZAWA Hiroyuki
2010-03-03  8:21             ` KAMEZAWA Hiroyuki
2010-03-03 11:50             ` Andrea Righi
2010-03-03 11:50               ` Andrea Righi
     [not found]             ` <20100303172132.fc6d9387.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2010-03-03 11:50               ` Andrea Righi
2010-03-03 22:03               ` Andrea Righi
2010-03-03 22:03             ` Andrea Righi
2010-03-03 22:03               ` Andrea Righi
2010-03-03 23:25               ` Daisuke Nishimura
2010-03-03 23:25               ` Daisuke Nishimura
2010-03-03 23:25                 ` Daisuke Nishimura
2010-03-04  3:45               ` KAMEZAWA Hiroyuki
2010-03-04  3:45               ` KAMEZAWA Hiroyuki
2010-03-04  3:45                 ` KAMEZAWA Hiroyuki
     [not found]       ` <20100303122906.9c613ab2.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2010-03-03  6:01         ` Daisuke Nishimura
     [not found]     ` <20100303111238.7133f8af.nishimura-YQH0OdQVrdy45+QrQBaojngSJqDPrsil@public.gmane.org>
2010-03-03  3:29       ` KAMEZAWA Hiroyuki

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=20100302215016.GA2369@linux \
    --to=arighi@develer.com \
    --cc=akpm@linux-foundation.org \
    --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=suleiman@google.com \
    /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: link
Be 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.