Hello, Michal. On Tue, Jun 04, 2013 at 03:18:43PM +0200, Michal Hocko wrote: > > + 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 don't get why that is a problem. Can you please elaborate? css's now explicitly allow holding onto them. We now have clear separation of "destruction" and "release" and blkcg also depends on it. If memcg still doesn't distinguish the two properly, that's where the problem should be fixed. > 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. I find the above really weird. If css can't be pinned for position caching, isn't it natural to ask why it can't be and then fix it? Because that's what the whole refcnt thing is about and a usage which cgroup explicitly allows (e.g. blkcg also does it). Why do you go from there to "this batshit crazy barrier dancing is the only solution"? Can you please explain why memcg css's can't be pinned? Thanks. -- tejun -- 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>