[PATCH cgroup/for-3.11] cgroup: disallow rename(2) if sane_behavior

Michal Hocko mhocko at suse.cz
Mon Jun 17 13:51:22 UTC 2013


On Sun 16-06-13 15:15:56, Tejun Heo wrote:
> Hey, Lennart.
> 
> On Sun, Jun 16, 2013 at 09:16:48AM +0200, Lennart Poettering wrote:
> > Note that in the long run I'd really like to see functionality added to
> > move a full cgroup subtree to a different point in the tree, so that we
> > can migrate containers and such atomically from one partition to
> 
> As some configurations are still affected by who one's parent is, we
> can't do migration using rename(2) right now. 

> Some configurations which are legitimate under the current parent
> might be invalid when put under a different parent. 

yes, for example all configurations where old parent is more restrictive
than the new one. For example. hardlimit in memcg or even more
oom_control, swappiness or use_hierarchy which are expected to be
consistent down the hierarchy.

> For migration to
> work, all configurations should be composable, which currently isn't
> true.  Off the top of my head, I think the offending ones are cpuset
> and device_cgroup, and I *think* the scheme Michal proposed at LSF
> breaks composability.

The biggest problem I can see is how the core cgroup code know when it is
OK to migrate. There might be some ongoing operations that depend on the
current tree structure. For example the hierarchical reclaim or oom
etc..

I do not think that soft reclaim which I was talking about at LSF would
change anything here as it would be pretty much the same as the hard
limit. But that is not so important.

> In general, configuration composability is something we want.  We
> don't want descendant configs being updated or becoming invalid as
> configurations of an ancestor change - any configuration should be
> valid.  The effects of some configurations could be no-op depending on
> how the ancestors are configured, but that's just the configuration
> being interpreted within the limits of its ancestors.
> 
> Li is working to make cpuset composable.  As for device_cgroup, I'm
> not sure what to do.  Aristeu, I know you already put in too much work
> into devcg and I'm sorry that I'm raising this now but would you be
> interested in tackling this too?
> 
> We want composability regardless of migration, but as for migration
> itself, an alternative could be having an atomic "move everything in
> cgroup A to cgroup B" interface, so that the admin (whether human or
> base system software) can set up a new cgroup and then move the member
> tasks atomically.
> 
> > another, without the container having to be aware of this (which of
> > course implies that we have a somewhat more useful cgroup namespacing
> > solution in place).
> 
> But such approach would definitely be visible to containers.  :(
> 
> Thanks.
> 
> -- 
> tejun

-- 
Michal Hocko
SUSE Labs


More information about the Containers mailing list