Tejun Heo wrote: > Currently, cgroup removal tries to drain all css references. If there > are active css references, the removal logic waits and retries > ->pre_detroy() until either all refs drop to zero or removal is > cancelled. > I don't like this either. > This semantics is unusual and adds non-trivial complexity to cgroup > core and IMHO is fundamentally misguided in that it couples internal > implementation details (references to internal data structure) with > externally visible operation (rmdir). To userland, this is a behavior > peculiarity which is unnecessary and difficult to expect (css refs is > otherwise invisible from userland), and, to policy implementations, > this is an unnecessary restriction (e.g. blkcg wants to hold css refs > for caching purposes but can't as that becomes visible as rmdir hang). > > Unfortunately, memcg currently depends on ->pre_destroy() retrials and > cgroup removal vetoing and can't be immmediately switched to the new > behavior. This patch introduces the new behavior of not waiting for > css refs to drain and maintains the old behavior for subsystems which > have __DEPRECATED_clear_css_refs set. > > Once, memcg is updated, we can drop the code paths for the old > behavior as proposed in the following patch. Note that the following > patch is incorrect in that dput work item is in cgroup and may lose > some of dputs when multiples css's are released back-to-back, and > __css_put() triggers check_for_release() when refcnt reaches 0 instead > of 1; however, it shows what part can be removed. > > http://thread.gmane.org/gmane.linux.kernel.containers/22559/focus=75251 > > Note that, in not-too-distant future, cgroup core will start emitting > warning messages for subsys which require the old behavior, so please > get moving. > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> Both patches look good. Acked-by: Li Zefan <lizefan@xxxxxxxxxx> and I'd like to see code shrink with memcg updates ASAP. > Cc: Vivek Goyal <vgoyal@xxxxxxxxxx> > Cc: Johannes Weiner <hannes@xxxxxxxxxxx> > Cc: Michal Hocko <mhocko@xxxxxxx> > Cc: Balbir Singh <bsingharora@xxxxxxxxx> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
