On Mon, Jun 17, 2013 at 06:33:53PM +0200, Lennart Poettering wrote: > On Sun, 16.06.13 15:15, Tejun Heo (tj@xxxxxxxxxx) wrote: > > > 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. > > I am not sure this would cut it for containers. For containers we'll > usually have a fully populated cgroup subtree, and if we want to migrate > that somewhere else, then we'd something that works recursively and > allows us to not tell the container at all about the move (i.e. the > namespace of cgroupfs the container sees should ideall stay entirely > unaltered by the move). Right, I somehow completely forgot about the sub-hierarchy. We can require the userland to set up the same sub-hierarchy with new configs and do migration recursively but that's just yucky and there's no way to make such operations invisible to the users of the sub-hierarchy. If we're gonna do it, I agree the only sane way is properly implementing migration via rename(2). Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
