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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>