On 11/7/06, Paul Menage <[EMAIL PROTECTED]> wrote: > > Perhaps the interface to binding multiple controllers to a single container > > hierarchy is via multiple mount commands, each of type 'container', with > > different options specifying which controller(s) to bind. Then the > > command 'mount -t cpuset cpuset /dev/cpuset' gets remapped to the command > > 'mount -t container -o controller=cpuset /dev/cpuset'. > > Yes, that's the aproach that I'm thinking of currently. It should > require pretty reasonably robotic changes to the existing code.
One drawback to this that I can see is the following: - suppose you mount a containerfs with controllers cpuset and cpu, and create some nodes, and then unmount it, what happens? do the resource nodes stick around still? - suppose you then try to mount a containers with controllers cpuset and diskio, but the resource nodes are still around, what happens then? Is there any way to prevent unmounting (at the dentry level) a busy filesystem? If we enforced a completely separate hierarchy for each resource controller (i.e. one resource controller per mount), then it wouldn't be too hard to hang the node structure off the controller itself, and there would never be a problem with mounting two controllers with existing inconsistent hierarchies on the same mount. But that would rule out being able to hook several resource controllers together in the same container node. One alternative to this would be to have a fixed number of container hierarchies; at mount time you'd mount hierarchy N, and optionally bind a set of resource controllers to it, or else use the existing set. Then the hierarchy can be hung off the appropriate entry in the hierarchy array even when the fs isn't mounted. Paul ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
