(2012/03/21 13:48), Aneesh Kumar K.V wrote:

Glauber Costa [off-list ref] writes:

quoted

On 03/19/2012 11:00 AM, KAMEZAWA Hiroyuki wrote:

quoted

(2012/03/19 15:52), Aneesh Kumar K.V wrote:

quoted

quoted

quoted

+#ifdef CONFIG_MEM_RES_CTLR_HUGETLB
+static bool mem_cgroup_have_hugetlb_usage(struct mem_cgroup *memcg)
+{
+	int idx;
+	for (idx = 0; idx<  hugetlb_max_hstate; idx++) {
+		if (memcg->hugepage[idx].usage>  0)
+			return 1;
+	}
+	return 0;
+}

Please use res_counter_read_u64() rather than reading the value directly.

The open-coded variant is mostly derived from mem_cgroup_force_empty. I
have updated the patch to use res_counter_read_u64.

Ah, ok. it's(maybe) my bad. I'll schedule a fix.

Kame,

I actually have it ready here. I can submit it if you want.

This one has bitten me as well when I was trying to experiment with the 
res_counter performance...

Do we really need memcg.res.usage to be accurate in that while loop ? If
we miss a zero update because we encountered a partial update; in the
next loop we will find it zero right ?

At rmdir(), I assume there is no task in memcg. It means res->usage never
increase and no other thread than force_empty will touch res->counter.
So, I think memcg->res.usage > 0 never be wrong and we'll find correct comparison
by continuing the loop.

But recent kmem accounting at el may break the assumption (I'm not fully sure..)
So, I think it will be good to use res_counter_u64(). This part is not important for
performance, anyway.

Thanks,
-Kame