[PATCH 1/2] memcg: rename mem_cgroup_zone_nr_pages() to mem_cgroup_zone_nr_lru_pages()

[PATCH 1/2] memcg: rename mem_cgroup_zone_nr_pages() to mem_cgroup_zone_nr_lru_pages()

[Ying Han]

The caller of the function has been renamed to zone_nr_lru_pages(), and this
is just fixing up in the memcg code. The current name is easily to be mis-read
as zone's total number of pages.

Signed-off-by: Ying Han <yinghan@google.com>
---
 include/linux/memcontrol.h |   10 +++++-----
 mm/memcontrol.c            |    6 +++---
 mm/vmscan.c                |    2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 77e47f5..22b3190 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -109,9 +109,9 @@ extern void mem_cgroup_end_migration(struct mem_cgroup *mem,
 int mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg);
 int mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg);
 int mem_cgroup_select_victim_node(struct mem_cgroup *memcg);
-unsigned long mem_cgroup_zone_nr_pages(struct mem_cgroup *memcg,
-				       struct zone *zone,
-				       enum lru_list lru);
+unsigned long mem_cgroup_zone_nr_lru_pages(struct mem_cgroup *memcg,
+						struct zone *zone,
+						enum lru_list lru);
 struct zone_reclaim_stat *mem_cgroup_get_reclaim_stat(struct mem_cgroup *memcg,
 						      struct zone *zone);
 struct zone_reclaim_stat*
@@ -306,8 +306,8 @@ mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg)
 }
 
 static inline unsigned long
-mem_cgroup_zone_nr_pages(struct mem_cgroup *memcg, struct zone *zone,
-			 enum lru_list lru)
+mem_cgroup_zone_nr_lru_pages(struct mem_cgroup *memcg, struct zone *zone,
+			     enum lru_list lru)
 {
 	return 0;
 }
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 95aecca..da183dc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1151,9 +1151,9 @@ int mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg)
 	return (active > inactive);
 }
 
-unsigned long mem_cgroup_zone_nr_pages(struct mem_cgroup *memcg,
-				       struct zone *zone,
-				       enum lru_list lru)
+unsigned long mem_cgroup_zone_nr_lru_pages(struct mem_cgroup *memcg,
+						struct zone *zone,
+						enum lru_list lru)
 {
 	int nid = zone_to_nid(zone);
 	int zid = zone_idx(zone);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 292582c..fbbb958 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -172,7 +172,7 @@ static unsigned long zone_nr_lru_pages(struct zone *zone,
 				struct scan_control *sc, enum lru_list lru)
 {
 	if (!scanning_global_lru(sc))
-		return mem_cgroup_zone_nr_pages(sc->mem_cgroup, zone, lru);
+		return mem_cgroup_zone_nr_lru_pages(sc->mem_cgroup, zone, lru);
 
 	return zone_page_state(zone, NR_LRU_BASE + lru);
 }
-- 
1.7.3.1

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

[PATCH 2/2] memcg: add memory.numastat api for numa statistics

[Ying Han]

The new API exports numa_maps per-memcg basis. This is a piece of useful
information where it exports per-memcg page distribution across real numa
nodes.

One of the usecase is evaluating application performance by combining this
information w/ the cpu allocation to the application.

The output of the memory.numastat tries to follow w/ simiar format of numa_maps
like:

<total pages> N0=<node 0 pages> N1=<node 1 pages> ...

$ cat /dev/cgroup/memory/memory.numa_stat
292115 N0=36364 N1=166876 N2=39741 N3=49115

Note: I noticed <total pages> is not equal to the sum of the rest of counters.
I might need to change the way get that counter, comments are welcomed.

Signed-off-by: Ying Han <yinghan@google.com>
---
 mm/memcontrol.c |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 53 insertions(+), 0 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index da183dc..0fe9c75 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1162,6 +1162,22 @@ unsigned long mem_cgroup_zone_nr_lru_pages(struct mem_cgroup *memcg,
 	return MEM_CGROUP_ZSTAT(mz, lru);
 }
 
+unsigned long mem_cgroup_node_nr_pages(struct mem_cgroup *memcg, int nid)
+{
+	int zid;
+	struct mem_cgroup_per_zone *mz;
+	enum lru_list l;
+	u64 total = 0;
+
+	for (zid = 0; zid < MAX_NR_ZONES; zid++) {
+		mz = mem_cgroup_zoneinfo(memcg, nid, zid);
+		for_each_lru(l)
+			total += MEM_CGROUP_ZSTAT(mz, l);
+	}
+
+	return total;
+}
+
 struct zone_reclaim_stat *mem_cgroup_get_reclaim_stat(struct mem_cgroup *memcg,
 						      struct zone *zone)
 {
@@ -4048,6 +4064,25 @@ mem_cgroup_get_total_stat(struct mem_cgroup *mem, struct mcs_total_stat *s)
 		mem_cgroup_get_local_stat(iter, s);
 }
 
+static int mem_control_numa_stat_show(struct seq_file *m, void *arg)
+{
+	int nid;
+	unsigned long total_nr, nid_nr;
+	struct cgroup *cont = m->private;
+	struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cont);
+
+	total_nr = mem_cgroup_local_usage(mem_cont);
+	seq_printf(m, "%lu", total_nr);
+
+	for_each_node_state(nid, N_HIGH_MEMORY) {
+		nid_nr = mem_cgroup_node_nr_pages(mem_cont, nid);
+		seq_printf(m, " N%d=%lu", nid, nid_nr);
+	}
+	seq_putc(m, '\n');
+
+	return 0;
+}
+
 static int mem_control_stat_show(struct cgroup *cont, struct cftype *cft,
 				 struct cgroup_map_cb *cb)
 {
@@ -4481,6 +4516,20 @@ static int mem_cgroup_oom_control_write(struct cgroup *cgrp,
 	return 0;
 }
 
+static const struct file_operations mem_control_numa_stat_file_operations = {
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
+static int mem_control_numa_stat_open(struct inode *unused, struct file *file)
+{
+	struct cgroup *cont = file->f_dentry->d_parent->d_fsdata;
+
+	file->f_op = &mem_control_numa_stat_file_operations;
+	return single_open(file, mem_control_numa_stat_show, cont);
+}
+
 static struct cftype mem_cgroup_files[] = {
 	{
 		.name = "usage_in_bytes",
@@ -4544,6 +4593,10 @@ static struct cftype mem_cgroup_files[] = {
 		.unregister_event = mem_cgroup_oom_unregister_event,
 		.private = MEMFILE_PRIVATE(_OOM_TYPE, OOM_CONTROL),
 	},
+	{
+		.name = "numa_stat",
+		.open = mem_control_numa_stat_open,
+	},
 };
 
 #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP
-- 
1.7.3.1

--
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 2/2] memcg: add memory.numastat api for numa statistics

[KAMEZAWA Hiroyuki]

On Tue, 17 May 2011 15:25:51 -0700
Ying Han <yinghan@google.com> wrote:

> The new API exports numa_maps per-memcg basis. This is a piece of useful
> information where it exports per-memcg page distribution across real numa
> nodes.
> 
> One of the usecase is evaluating application performance by combining this
> information w/ the cpu allocation to the application.
> 
> The output of the memory.numastat tries to follow w/ simiar format of numa_maps
> like:
> 
> <total pages> N0=<node 0 pages> N1=<node 1 pages> ...
> 
> $ cat /dev/cgroup/memory/memory.numa_stat
> 292115 N0=36364 N1=166876 N2=39741 N3=49115
> 
> Note: I noticed <total pages> is not equal to the sum of the rest of counters.
> I might need to change the way get that counter, comments are welcomed.
> 
> Signed-off-by: Ying Han <yinghan@google.com>

Hmm, If I'm a user, I want to know file-cache is well balanced or where Anon is
allocated from....Can't we have more precice one rather than total(anon+file) ?

So, I don't like this patch. Could you show total,anon,file at least ?

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>

Re: [PATCH 2/2] memcg: add memory.numastat api for numa statistics

[Ying Han]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Tue, May 17, 2011 at 4:52 PM, KAMEZAWA Hiroyuki <
kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Tue, 17 May 2011 15:25:51 -0700
> Ying Han <yinghan@google.com> wrote:
>
> > The new API exports numa_maps per-memcg basis. This is a piece of useful
> > information where it exports per-memcg page distribution across real numa
> > nodes.
> >
> > One of the usecase is evaluating application performance by combining
> this
> > information w/ the cpu allocation to the application.
> >
> > The output of the memory.numastat tries to follow w/ simiar format of
> numa_maps
> > like:
> >
> > <total pages> N0=<node 0 pages> N1=<node 1 pages> ...
> >
> > $ cat /dev/cgroup/memory/memory.numa_stat
> > 292115 N0=36364 N1=166876 N2=39741 N3=49115
> >
> > Note: I noticed <total pages> is not equal to the sum of the rest of
> counters.
> > I might need to change the way get that counter, comments are welcomed.
> >
> > Signed-off-by: Ying Han <yinghan@google.com>
>
> Hmm, If I'm a user, I want to know file-cache is well balanced or where
> Anon is
> allocated from....Can't we have more precice one rather than
> total(anon+file) ?
>
> So, I don't like this patch. Could you show total,anon,file at least ?
>

Ok, then this is really becoming per-memcg numa_maps. Before I go ahead
posting the next version, this is something we are looking for:

total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...

please confirm?

thanks

--Ying

> Thanks,
> -Kame
>
>

[-- Attachment #2: Type: text/html, Size: 2635 bytes --]

Re: [PATCH 2/2] memcg: add memory.numastat api for numa statistics

[KAMEZAWA Hiroyuki]

On Tue, 17 May 2011 18:40:23 -0700
Ying Han <yinghan@google.com> wrote:

> On Tue, May 17, 2011 at 4:52 PM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 
> > On Tue, 17 May 2011 15:25:51 -0700
> > Ying Han <yinghan@google.com> wrote:
> >
> > > The new API exports numa_maps per-memcg basis. This is a piece of useful
> > > information where it exports per-memcg page distribution across real numa
> > > nodes.
> > >
> > > One of the usecase is evaluating application performance by combining
> > this
> > > information w/ the cpu allocation to the application.
> > >
> > > The output of the memory.numastat tries to follow w/ simiar format of
> > numa_maps
> > > like:
> > >
> > > <total pages> N0=<node 0 pages> N1=<node 1 pages> ...
> > >
> > > $ cat /dev/cgroup/memory/memory.numa_stat
> > > 292115 N0=36364 N1=166876 N2=39741 N3=49115
> > >
> > > Note: I noticed <total pages> is not equal to the sum of the rest of
> > counters.
> > > I might need to change the way get that counter, comments are welcomed.
> > >
> > > Signed-off-by: Ying Han <yinghan@google.com>
> >
> > Hmm, If I'm a user, I want to know file-cache is well balanced or where
> > Anon is
> > allocated from....Can't we have more precice one rather than
> > total(anon+file) ?
> >
> > So, I don't like this patch. Could you show total,anon,file at least ?
> >
> 
> Ok, then this is really becoming per-memcg numa_maps. Before I go ahead
> posting the next version, this is something we are looking for:
> 
> total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
> anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
> file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
> 

seems good.

THanks,
-Kmae

--
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 2/2] memcg: add memory.numastat api for numa statistics

[Ying Han]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

On Tue, May 17, 2011 at 7:08 PM, KAMEZAWA Hiroyuki <
kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Tue, 17 May 2011 18:40:23 -0700
> Ying Han <yinghan@google.com> wrote:
>
> > On Tue, May 17, 2011 at 4:52 PM, KAMEZAWA Hiroyuki <
> > kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > > On Tue, 17 May 2011 15:25:51 -0700
> > > Ying Han <yinghan@google.com> wrote:
> > >
> > > > The new API exports numa_maps per-memcg basis. This is a piece of
> useful
> > > > information where it exports per-memcg page distribution across real
> numa
> > > > nodes.
> > > >
> > > > One of the usecase is evaluating application performance by combining
> > > this
> > > > information w/ the cpu allocation to the application.
> > > >
> > > > The output of the memory.numastat tries to follow w/ simiar format of
> > > numa_maps
> > > > like:
> > > >
> > > > <total pages> N0=<node 0 pages> N1=<node 1 pages> ...
> > > >
> > > > $ cat /dev/cgroup/memory/memory.numa_stat
> > > > 292115 N0=36364 N1=166876 N2=39741 N3=49115
> > > >
> > > > Note: I noticed <total pages> is not equal to the sum of the rest of
> > > counters.
> > > > I might need to change the way get that counter, comments are
> welcomed.
> > > >
> > > > Signed-off-by: Ying Han <yinghan@google.com>
> > >
> > > Hmm, If I'm a user, I want to know file-cache is well balanced or where
> > > Anon is
> > > allocated from....Can't we have more precice one rather than
> > > total(anon+file) ?
> > >
> > > So, I don't like this patch. Could you show total,anon,file at least ?
> > >
> >
> > Ok, then this is really becoming per-memcg numa_maps. Before I go ahead
> > posting the next version, this is something we are looking for:
> >
> > total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
> > anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
> > file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
> >
>
> seems good.
>

Ok, thank you for clarifying that. I will look into the next post then.

--Ying

>
> THanks,
> -Kmae
>
>

[-- Attachment #2: Type: text/html, Size: 3187 bytes --]