[PATCH 3/3] memcgoup: allow memory.failcnt to be reset

From: Li Zefan
Date: Tue Mar 11 2008 - 06:17:23 EST


Allow memory.failcnt to be reset to 0:

echo 0 > memory.failcnt

And '0' is the only valid value.

This is useful when testing or observing the memory resource
controller. Without this function, one will have to remember
the previous failcnt to decide whether memory reclaim has
happened *again*.

Signed-off-by: Li Zefan <lizf@xxxxxxxxxxxxxx>
---
Documentation/controllers/memory.txt | 4 +++-
mm/memcontrol.c | 15 +++++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/Documentation/controllers/memory.txt b/Documentation/controllers/memory.txt
index 866b9cd..28f80e3 100644
--- a/Documentation/controllers/memory.txt
+++ b/Documentation/controllers/memory.txt
@@ -194,7 +194,9 @@ this file after a write to guarantee the value committed by the kernel.
4096

The memory.failcnt field gives the number of times that the cgroup limit was
-exceeded.
+exceeded. It can be reset.
+
+# echo 0 > memory.failcnt

The memory.stat file gives accounting information. Now, the number of
caches, RSS and Active pages/Inactive pages are shown.
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6145031..fd26dc2 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -883,6 +883,20 @@ static int mem_force_empty_write(struct cgroup *cont, struct cftype *cft,
return ret;
}

+static int mem_failcnt_write(struct cgroup *cont, struct cftype *cft,
+ u64 val)
+{
+ struct res_counter *counter;
+
+ if (val != 0)
+ return -EINVAL;
+
+ counter = &mem_cgroup_from_cont(cont)->res;
+ res_counter_write_u64(counter, cft->private, 0);
+
+ return 0;
+}
+
static const struct mem_cgroup_stat_desc {
const char *msg;
u64 unit;
@@ -934,6 +948,7 @@ static struct cftype mem_cgroup_files[] = {
{
.name = "failcnt",
.private = RES_FAILCNT,
+ .write_u64 = mem_failcnt_write,
.read_u64 = mem_cgroup_read,
},
{
--
1.5.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/