On Fri 16-03-12 23:09:24, Aneesh Kumar K.V wrote: [...] > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 6728a7a..4b36c5e 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c [...] > @@ -4887,6 +5013,7 @@ err_cleanup: > static struct cgroup_subsys_state * __ref > mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) > { > + int idx; > struct mem_cgroup *memcg, *parent; > long error = -ENOMEM; > int node; > @@ -4929,9 +5056,14 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) > * mem_cgroup(see mem_cgroup_put). > */ > mem_cgroup_get(parent); > + for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) > + res_counter_init(&memcg->hugepage[idx], > + &parent->hugepage[idx]); Hmm, I do not think we want to make groups deeper in the hierarchy unlimited as we cannot reclaim. Shouldn't we copy the limit from the parent? Still not ideal but slightly more expected behavior IMO. The hierarchy setups are still interesting and the limitations should be described in the documentation... > } else { > res_counter_init(&memcg->res, NULL); > res_counter_init(&memcg->memsw, NULL); > + for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) > + res_counter_init(&memcg->hugepage[idx], NULL); > } > memcg->last_scanned_node = MAX_NUMNODES; > INIT_LIST_HEAD(&memcg->oom_notify); -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html