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. 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. 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
