[PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>

Expose the failcnt details to userspace similar to memory and memsw.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
 include/linux/hugetlb.h |    2 +-
 mm/memcontrol.c         |   40 ++++++++++++++++++++++++++--------------
 2 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index ee80bc8..cfe3cf5c 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -219,7 +219,7 @@ struct hstate {
 	unsigned int surplus_huge_pages_node[MAX_NUMNODES];
 #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
 	/* mem cgroup control files */
-	struct cftype mem_cgroup_files[4];
+	struct cftype mem_cgroup_files[5];
 #endif
 	char name[HSTATE_NAME_LEN];
 };
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f142ea9..bacb0df 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4189,7 +4189,7 @@ out:
 static int mem_cgroup_reset(struct cgroup *cont, unsigned int event)
 {
 	struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
-	int type, name;
+	int type, name, idx;
 
 	type = MEMFILE_TYPE(event);
 	name = MEMFILE_ATTR(event);
@@ -4197,24 +4197,29 @@ static int mem_cgroup_reset(struct cgroup *cont, unsigned int event)
 	if (!do_swap_account && type == _MEMSWAP)
 		return -EOPNOTSUPP;
 
-	switch (name) {
-	case RES_MAX_USAGE:
-		if (type == _MEM)
+	switch (type) {
+	case _MEM:
+		if (name == RES_MAX_USAGE)
 			res_counter_reset_max(&memcg->res);
-		else if (type == _MEMHUGETLB) {
-			int idx = MEMFILE_IDX(event);
-			res_counter_reset_max(&memcg->hugepage[idx]);
-		} else
-			res_counter_reset_max(&memcg->memsw);
-		break;
-	case RES_FAILCNT:
-		if (type == _MEM)
+		else
 			res_counter_reset_failcnt(&memcg->res);
+		break;
+	case _MEMSWAP:
+		if (name == RES_MAX_USAGE)
+			res_counter_reset_max(&memcg->memsw);
 		else
 			res_counter_reset_failcnt(&memcg->memsw);
 		break;
+	case _MEMHUGETLB:
+		idx = MEMFILE_IDX(event);
+		if (name == RES_MAX_USAGE)
+			res_counter_reset_max(&memcg->hugepage[idx]);
+		else
+			res_counter_reset_failcnt(&memcg->hugepage[idx]);
+		break;
+	default:
+		BUG();
 	}
-
 	return 0;
 }
 
@@ -5299,8 +5304,15 @@ int __init mem_cgroup_hugetlb_file_init(int idx)
 	cft->trigger  = mem_cgroup_reset;
 	cft->read = mem_cgroup_read;
 
-	/* NULL terminate the last cft */
+	/* Add the failcntfile */
 	cft = &h->mem_cgroup_files[3];
+	snprintf(cft->name, MAX_CFTYPE_NAME, "hugetlb.%s.failcnt", buf);
+	cft->private  = __MEMFILE_PRIVATE(idx, _MEMHUGETLB, RES_FAILCNT);
+	cft->trigger  = mem_cgroup_reset;
+	cft->read = mem_cgroup_read;
+
+	/* NULL terminate the last cft */
+	cft = &h->mem_cgroup_files[4];
 	memset(cft, 0, sizeof(*cft));
 
 	WARN_ON(cgroup_add_cftypes(&mem_cgroup_subsys, h->mem_cgroup_files));
-- 
1.7.10

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[Andrew Morton]

On Tue, 22 May 2012 17:13:11 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> Expose the failcnt details to userspace similar to memory and memsw.

Why?

In general, it is best not to add any new userspace interfaces at all. 
We will do so, if there are good reasons.  But you've provided no reason
at all.

>  include/linux/hugetlb.h |    2 +-
>  mm/memcontrol.c         |   40 ++++++++++++++++++++++++++--------------

Documentation/cgroups/memory.txt needs updating also.  You modify the
user insterface, you modify documentation - this should be automatic
for all of us.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[Aneesh Kumar K.V]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 22 May 2012 17:13:11 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> Expose the failcnt details to userspace similar to memory and memsw.
>
> Why?
>

to help us find whether there was an allocation failure due to HugeTLB
limit. 

> In general, it is best not to add any new userspace interfaces at all. 
> We will do so, if there are good reasons.  But you've provided no reason
> at all.
>
>>  include/linux/hugetlb.h |    2 +-
>>  mm/memcontrol.c         |   40 ++++++++++++++++++++++++++--------------
>
> Documentation/cgroups/memory.txt needs updating also.  You modify the
> user insterface, you modify documentation - this should be automatic
> for all of us.

How about the below

diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 730e222a..3a47ec5 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -80,6 +80,7 @@ Brief summary of control files.
  memory.hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb  usage recorded
  memory.hugetlb.<hugepagesize>.usage_in_bytes     # show current res_counter usage for "hugepagesize" hugetlb
 						  # see 5.7 for details
+ memory.hugetlb.<hugepagesize>.failcnt		  # show the number of allocation failure due to HugeTLB limit
 
 1. History
 

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[Andrew Morton]

On Thu, 24 May 2012 10:10:00 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue, 22 May 2012 17:13:11 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> >
> >> Expose the failcnt details to userspace similar to memory and memsw.
> >
> > Why?
> >
> 
> to help us find whether there was an allocation failure due to HugeTLB
> limit. 

How are we to know that is that useful enough to justify expanding the
kernel API?

Yes, regular memcg has it, but that isn't a reason.  Do we know that
people are using that?  That it is useful?

Also, "cnt" is not a word.  It should be "failcount" or, even better,
"failure_count".  Or, smarter, "failures".  But we screwed that up a
long time ago and can't fix it.


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] memcg/hugetlb: Add failcnt support for hugetlb extension

[KAMEZAWA Hiroyuki]

(2012/05/24 14:16), Andrew Morton wrote:

> On Thu, 24 May 2012 10:10:00 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> 
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Tue, 22 May 2012 17:13:11 +0530
>>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>>
>>>> Expose the failcnt details to userspace similar to memory and memsw.
>>>
>>> Why?
>>>
>>
>> to help us find whether there was an allocation failure due to HugeTLB
>> limit. 
> 
> How are we to know that is that useful enough to justify expanding the
> kernel API?
> 
> Yes, regular memcg has it, but that isn't a reason.  Do we know that
> people are using that?  That it is useful?
> 
> Also, "cnt" is not a word.  It should be "failcount" or, even better,
> "failure_count".  Or, smarter, "failures".  But we screwed that up a
> long time ago and can't fix it.

It has been there since the first commit of memcg...before I joined.

I sometimes use failcnt to confirm whether an application/benchmark hits
the limit and memory reclaim run by limit or not.

With hugetlb, it has no memory reclaim...'allocation failure by limit'
is informed as -ENOSPC to applications. It seems there 3 reasons of -ENOSPC.
memcg-limit and page-allocation-failure and failure in subpool_get_pages().

I think failcnt may be useful because users may want to know the cause of -ENOSPC
after application exits by seeing -ENOSPC. If failcnt > 0, he will tweak the limit
or check application size. Of course, someone may be able to think of other UI.

Thanks,
-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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>