Re: [RFC][1/3] memcg clean up try charge

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Tue, 1 Jun 2010 17:06:58 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-06-01 18:24:06]:
> >    why we retry or quit by return code.
> > 
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> >  mm/memcontrol.c |  244 +++++++++++++++++++++++++++++++++-----------------------
> >  1 file changed, 145 insertions(+), 99 deletions(-)
> > 
> > Index: mmotm-2.6.34-May21/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-2.6.34-May21.orig/mm/memcontrol.c
> > +++ mmotm-2.6.34-May21/mm/memcontrol.c
> > @@ -1072,6 +1072,49 @@ static unsigned int get_swappiness(struc
> >  	return swappiness;
> >  }
> > 
> > +/* A routine for testing mem is not under move_account */
> > +
> > +static bool mem_cgroup_under_move(struct mem_cgroup *mem)
> > +{
> > +	struct mem_cgroup *from = mc.from;
> > +	struct mem_cgroup *to = mc.to;
> > +	bool ret = false;
> > +
> > +	if (from == mem || to == mem)
> > +		return true;
> > +
> > +	if (!from || !to || !mem->use_hierarchy)
> > +		return false;
> > +
> > +	rcu_read_lock();
> > +	if (css_tryget(&from->css)) {
> > +		ret = css_is_ancestor(&from->css, &mem->css);
> > +		css_put(&from->css);
> > +	}
> > +	if (!ret && css_tryget(&to->css)) {
> > +		ret = css_is_ancestor(&to->css,	&mem->css);
> > +		css_put(&to->css);
> > +	}
> > +	rcu_read_unlock();
> > +	return ret;
> > +}
> > +
> > +static bool mem_cgroup_wait_acct_move(struct mem_cgroup *mem)
> > +{
> > +	if (mc.moving_task && current != mc.moving_task) {
> > +		if (mem_cgroup_under_move(mem)) {
> > +			DEFINE_WAIT(wait);
> > +			prepare_to_wait(&mc.waitq, &wait, TASK_INTERRUPTIBLE);
> > +			/* moving charge context might have finished. */
> > +			if (mc.moving_task)
> > +				schedule();
> 
> If we sleep with TASK_INTERRUPTIBLE, we should also check for
> signal_pending() at the end of the schedule and handle it
> appropriately to cancel the operation. 
> 
Hmm. yes. and if signal is a fatal one, we can use "bypass" root.

> Looks good to me otherwise.

Thank you.

Regards,
-Kame
> 

> 




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