On Mon 03-06-13 17:44:39, Tejun Heo wrote: [...] > @@ -1267,7 +1226,20 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup *root, > break; > > iter->generation++; > + last_visited = NULL; > } > + > + /* > + * Update @iter to the new position. As multiple tasks could be > + * executing this path, atomically swap the new and old. We want > + * RCU assignment here but there's no rcu_xchg() and the plain > + * xchg() has enough memory barrier semantics. > + */ > + if (memcg) > + css_get(&memcg->css); This is all good and nice but it re-introduces the same problem which has been fixed by (5f578161: memcg: relax memcg iter caching). You are pinning memcg in memory for unbounded amount of time because css reference will not let object to leave and rest. I understand your frustration about the complexity of the current synchronization but we didn't come up with anything easier. Originally I though that your tree walk updates which allow dropping rcu would help here but then I realized that not really because the iterator (resp. pos) has to be a valid pointer and there is only one possibility to do that AFAICS here and that is css pinning. And is no-go. > + last_visited = xchg(&iter->last_visited, memcg); > + if (last_visited) > + css_put(&last_visited->css); > out_unlock: > rcu_read_unlock(); > out_css_put: [...] -- Michal Hocko SUSE Labs -- 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
