linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"menage@google.com" <menage@google.com>,
	"lizf@cn.fujitsu.com" <lizf@cn.fujitsu.com>,
	"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
	"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [RFC] [PATCH 7/7] memcg: background reclaim (example)
Date: Thu, 22 Jan 2009 18:41:57 +0900	[thread overview]
Message-ID: <20090122184157.2307bf5b.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20090122183411.3cabdfd2.kamezawa.hiroyu@jp.fujitsu.com>

A sample for background-reclaim for memcg using pdflush().

Just an example, any comments are welcome.
Maybe it needs some amount of more work/time to fix this patch.

This is a patch for background memory reclaim for memcg, like kswapd().
In this, pdflush() is used for reclaim some more memory when tasks
under memcg hits limit.

Note:
 - considering hierarchy, high-low watermark in the kernel seems to be
   very complex. My purpose is adding an funcitonality like kswapd().
   No performance test yet.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
 mm/memcontrol.c |   87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 85 insertions(+), 2 deletions(-)

Index: mmotm-2.6.29-Jan16/mm/memcontrol.c
===================================================================
--- mmotm-2.6.29-Jan16.orig/mm/memcontrol.c
+++ mmotm-2.6.29-Jan16/mm/memcontrol.c
@@ -37,7 +37,7 @@
 #include <linux/mm_inline.h>
 #include <linux/page_cgroup.h>
 #include "internal.h"
-
+#include <linux/writeback.h>
 #include <asm/uaccess.h>
 
 struct cgroup_subsys mem_cgroup_subsys __read_mostly;
@@ -166,6 +166,7 @@ struct mem_cgroup {
 	 * reclaimed from.
 	 */
 	int last_scanned_child;
+	int pdflush_called;
 	/*
 	 * Should the accounting and control be hierarchical, per subtree?
 	 */
@@ -297,7 +298,7 @@ static struct mem_cgroup *try_get_mem_cg
 	struct mem_cgroup *mem = NULL;
 
 	if (!mm)
-		return;
+		return NULL;
 	/*
 	 * Because we have no locks, mm->owner's may be being moved to other
 	 * cgroup. We use css_tryget() here even if this looks
@@ -771,6 +772,7 @@ mem_cgroup_select_victim(struct mem_cgro
 	return ret;
 }
 
+static void mem_cgroup_bg_reclaim(unsigned long arg0);
 /*
  * Scan the hierarchy if needed to reclaim memory. We remember the last child
  * we reclaimed from, so that we don't end up penalizing one child extensively
@@ -790,6 +792,17 @@ static int mem_cgroup_hierarchical_recla
 	int ret, total = 0;
 	int loop = 0;
 
+	if (!shrink) { /* memory usage hit limit */
+		if (!root_mem->pdflush_called) {
+			if (!pdflush_operation(mem_cgroup_bg_reclaim,
+					      css_id(&root_mem->css))) {
+				spin_lock(&root_mem->reclaim_param_lock);
+				root_mem->pdflush_called = 1;
+				spin_unlock(&root_mem->reclaim_param_lock);
+			}
+		}
+	}
+
 	while (loop < 2) {
 		victim = mem_cgroup_select_victim(root_mem);
 		if (victim == root_mem)
@@ -817,6 +830,76 @@ static int mem_cgroup_hierarchical_recla
 	return total;
 }
 
+/*
+ * Called when hierarchy reclaim triggered by memory limitation check.
+ * ID of hierarchy root is the argument.
+ */
+#define FREE_THRESH_RATIO	(95)	      /* 95% */
+#define FREE_THRESH_MAX		(1024 * 1024) /* 1M bytes*/
+#define FREE_THRESH_MIN		(128 * 1024)  /* 128kbytes */
+static u64 memcg_stable_free_thresh(u64 limit)
+{
+	u64 ret;
+
+	ret = limit * FREE_THRESH_RATIO/100;
+	/* backgroubd writeout is overkill to this cgroup ? */
+	if (ret < FREE_THRESH_MIN)
+		ret = 0;
+	if (ret > FREE_THRESH_MAX)
+		ret = FREE_THRESH_MAX;
+	return ret;
+}
+
+static void mem_cgroup_bg_reclaim(unsigned long arg0)
+{
+	struct cgroup_subsys_state *css;
+	struct mem_cgroup *mem = NULL;
+	u64 usage, limit;
+	bool memshortage, noswap;
+	int retry;
+
+	rcu_read_lock();
+	css = css_lookup(&mem_cgroup_subsys, arg0);
+	if (css && css_tryget(css))
+		mem = container_of(css, struct mem_cgroup, css);
+	rcu_read_unlock();
+	if (!mem)
+		return;
+	retry = mem_cgroup_count_children(mem);
+	while (retry--) {
+		/* check situation */
+		memshortage = false;
+		noswap = false;
+		usage = res_counter_read_u64(&mem->res, RES_USAGE);
+		limit = res_counter_read_u64(&mem->res, RES_LIMIT);
+
+		if (usage > limit - memcg_stable_free_thresh(limit))
+			memshortage = true;
+
+		if (do_swap_account) {
+			usage = res_counter_read_u64(&mem->res, RES_USAGE);
+			limit = res_counter_read_u64(&mem->res, RES_LIMIT);
+			if (usage > limit - memcg_stable_free_thresh(limit))
+				noswap = true;
+		}
+		if (memshortage || noswap)
+			mem_cgroup_hierarchical_reclaim(mem, GFP_KERNEL,
+							noswap, true);
+		else
+			break;
+		cond_resched();
+	}
+
+	spin_lock(&mem->reclaim_param_lock);
+	mem->pdflush_called = 0;
+	spin_unlock(&mem->reclaim_param_lock);
+	css_put(&mem->css);
+
+	return;
+}
+
+
+
 bool mem_cgroup_oom_called(struct task_struct *task)
 {
 	bool ret = false;

--
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:[~2009-01-22  9:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22  9:34 [PATCH 0/7] cgroup/memcg updates 2009/01/22 KAMEZAWA Hiroyuki
2009-01-22  9:35 ` [PATCH 1/7] cgroup: add CSS ID KAMEZAWA Hiroyuki
2009-01-23  6:02   ` Daisuke Nishimura
2009-01-22  9:35 ` [PATCH 2/7] memcg : use CSS ID in memcg KAMEZAWA Hiroyuki
2009-01-23  7:22   ` Daisuke Nishimura
2009-01-23  8:04     ` Daisuke Nishimura
2009-01-23  9:49     ` KAMEZAWA Hiroyuki
2009-01-22  9:36 ` [PATCH 3/7] memcg: show hierarchical stat KAMEZAWA Hiroyuki
2009-01-22  9:38 ` [FIX][PATCH 4/7] memcg : make set_limit return -EBUSY after reasonable retries KAMEZAWA Hiroyuki
2009-01-22  9:39 ` [FIX][PATCH 5/7] memcg : fix OOM Killer behavior under memcg KAMEZAWA Hiroyuki
2009-01-22  9:40 ` [FIX][PATCH 6/7] cgroup/memcg: fix frequent -EBUSY at rmdir KAMEZAWA Hiroyuki
2009-01-27  0:58   ` Randy Dunlap
2009-01-28  0:09     ` KAMEZAWA Hiroyuki
2009-01-22  9:41 ` KAMEZAWA Hiroyuki [this message]

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=20090122184157.2307bf5b.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    /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