linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: nishimura@mxp.nes.nec.co.jp, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, balbir@linux.vnet.ibm.com,
	lizf@cn.fujitsu.com, menage@google.com
Subject: Re: [RFC][PATCH 4/4] memcg: make oom less frequently
Date: Fri, 9 Jan 2009 10:44:16 +0900	[thread overview]
Message-ID: <20090109104416.9bf4aab7.nishimura@mxp.nes.nec.co.jp> (raw)
In-Reply-To: <44480.10.75.179.62.1231413588.squirrel@webmail-b.css.fujitsu.com>

On Thu, 8 Jan 2009 20:19:48 +0900 (JST), "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Daisuke Nishimura said:
> > In previous implementation, mem_cgroup_try_charge checked the return
> > value of mem_cgroup_try_to_free_pages, and just retried if some pages
> > had been reclaimed.
> > But now, try_charge(and mem_cgroup_hierarchical_reclaim called from it)
> > only checks whether the usage is less than the limit.
> >
> > This patch tries to change the behavior as before to cause oom less
> > frequently.
> >
> > To prevent try_charge from getting stuck in infinite loop,
> > MEM_CGROUP_RECLAIM_RETRIES_MAX is defined.
> >
> >
> > Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
> 
> I think this is necessary change.
> My version of hierarchy reclaim will do this.
> 
> But RETRIES_MAX is not clear ;) please use one counter.
> 
> And why MAX=32 ?
I inserted printk and counted the loop count on oom(tested with 4 children).
It seemed 32 would be enough.

> > +		if (ret)
> > +			continue;
> seems to do enough work.
> 
> While memory can be reclaimed, it's not dead lock.
I see.
I introduced this max count because mmap_sem might be hold for a long time
at page fault, but this is not "dead" lock as you say.

> To handle live-lock situation as "reclaimed memory is stolen very soon",
> should we check signal_pending(current) or some flags ?
> 
> IMHO, using jiffies to detect how long we should retry is easy to understand
> ....like
>  "if memory charging cannot make progress for XXXX minutes,
>   trigger some notifier or show some flag to user via cgroupfs interface.
>   to show we're tooooooo busy."
> 
Good Idea.

But I think it would be enough for now to check signal_pending(curren) and
return -ENOMEM.

How about this one?
===
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>

In previous implementation, mem_cgroup_try_charge checked the return
value of mem_cgroup_try_to_free_pages, and just retried if some pages
had been reclaimed.
But now, try_charge(and mem_cgroup_hierarchical_reclaim called from it)
only checks whether the usage is less than the limit.

This patch tries to change the behavior as before to cause oom less frequently.


Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
---
 mm/memcontrol.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dc38a0e..2ab0a5c 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -770,10 +770,10 @@ static int mem_cgroup_hierarchical_reclaim(struct mem_cgroup *root_mem,
 	 * but there might be left over accounting, even after children
 	 * have left.
 	 */
-	ret = try_to_free_mem_cgroup_pages(root_mem, gfp_mask, noswap,
+	ret += try_to_free_mem_cgroup_pages(root_mem, gfp_mask, noswap,
 					   get_swappiness(root_mem));
 	if (mem_cgroup_check_under_limit(root_mem))
-		return 0;
+		return 1;	/* indicate reclaim has succeeded */
 	if (!root_mem->use_hierarchy)
 		return ret;
 
@@ -784,10 +784,10 @@ static int mem_cgroup_hierarchical_reclaim(struct mem_cgroup *root_mem,
 			next_mem = mem_cgroup_get_next_node(root_mem);
 			continue;
 		}
-		ret = try_to_free_mem_cgroup_pages(next_mem, gfp_mask, noswap,
+		ret += try_to_free_mem_cgroup_pages(next_mem, gfp_mask, noswap,
 						   get_swappiness(next_mem));
 		if (mem_cgroup_check_under_limit(root_mem))
-			return 0;
+			return 1;	/* indicate reclaim has succeeded */
 		next_mem = mem_cgroup_get_next_node(root_mem);
 	}
 	return ret;
@@ -870,8 +870,13 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
 		if (!(gfp_mask & __GFP_WAIT))
 			goto nomem;
 
+		if (signal_pending(current))
+			goto oom;
+
 		ret = mem_cgroup_hierarchical_reclaim(mem_over_limit, gfp_mask,
 							noswap);
+		if (ret)
+			continue;
 
 		/*
 		 * try_to_free_mem_cgroup_pages() might not give us a full
@@ -885,6 +890,7 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
 			continue;
 
 		if (!nr_retries--) {
+oom:
 			if (oom) {
 				mutex_lock(&memcg_tasklist);
 				mem_cgroup_out_of_memory(mem_over_limit, gfp_mask);

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

  reply	other threads:[~2009-01-09  1:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08 10:08 [RFC][PATCH 0/4] some memcg fixes Daisuke Nishimura
2009-01-08 10:14 ` [RFC][PATCH 1/4] memcg: fix for mem_cgroup_get_reclaim_stat_from_page Daisuke Nishimura
2009-01-08 10:59   ` [RFC][PATCH 1/4] memcg: fix formem_cgroup_get_reclaim_stat_from_page KAMEZAWA Hiroyuki
2009-01-09  0:57   ` [RFC][PATCH 1/4] memcg: fix for mem_cgroup_get_reclaim_stat_from_page Li Zefan
2009-01-09  1:05     ` KAMEZAWA Hiroyuki
2009-01-09  2:34       ` Daisuke Nishimura
2009-01-09  2:41         ` KAMEZAWA Hiroyuki
2009-01-09  4:32   ` Balbir Singh
2009-01-09  4:47     ` KAMEZAWA Hiroyuki
2009-01-15 11:08       ` [PATCH] mark_page_accessed() in do_swap_page() move latter than memcg charge KOSAKI Motohiro
2009-01-15 11:12         ` KAMEZAWA Hiroyuki
2009-01-15 11:30         ` Balbir Singh
2009-01-15 12:07         ` Hugh Dickins
2009-01-15 12:28           ` KAMEZAWA Hiroyuki
2009-01-15 13:34           ` KOSAKI Motohiro
2009-01-15 13:43             ` KOSAKI Motohiro
2009-01-08 10:14 ` [RFC][PATCH 2/4] memcg: fix error path of mem_cgroup_move_parent Daisuke Nishimura
2009-01-08 11:00   ` KAMEZAWA Hiroyuki
2009-01-09  5:15   ` Balbir Singh
2009-01-09  5:33     ` Daisuke Nishimura
2009-01-09  6:01       ` Balbir Singh
2009-01-08 10:15 ` [RFC][PATCH 3/4] memcg: fix for mem_cgroup_hierarchical_reclaim Daisuke Nishimura
2009-01-08 11:08   ` KAMEZAWA Hiroyuki
2009-01-09  1:08     ` KAMEZAWA Hiroyuki
2009-01-09  2:51       ` Daisuke Nishimura
2009-01-09  3:09         ` KAMEZAWA Hiroyuki
2009-01-09  5:34           ` Balbir Singh
2009-01-09  5:33   ` Balbir Singh
2009-01-09  6:01     ` Daisuke Nishimura
2009-01-09  9:01       ` Daisuke Nishimura
2009-01-08 10:15 ` [RFC][PATCH 4/4] memcg: make oom less frequently Daisuke Nishimura
2009-01-08 11:19   ` KAMEZAWA Hiroyuki
2009-01-09  1:44     ` Daisuke Nishimura [this message]
2009-01-09  2:03       ` KAMEZAWA Hiroyuki
2009-01-09  2:29         ` Daisuke Nishimura
2009-01-09  2:39           ` KAMEZAWA Hiroyuki
2009-01-09  5:58   ` Balbir Singh
2009-01-09  8:52     ` Daisuke Nishimura
2009-01-09  9:03       ` Balbir Singh
2009-01-09  9:37         ` 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=20090109104416.9bf4aab7.nishimura@mxp.nes.nec.co.jp \
    --to=nishimura@mxp.nes.nec.co.jp \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox