On 11/1/06, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote: > > I suspect we can avoid maintaining separate hierarchies if not required. > > mkdir /dev/res_groups > mount -t container -o cpu,mem,io none /dev/res_groups > mkdir /dev/res_groups/A > mkdir /dev/res_groups/B > > Directories A and B would now contain res ctl files associated with all > resources (viz cpu, mem, io) and also a 'members' file listing the tasks > belonging to those groups. > > Do you think the above mechanism is implementable? Even if it is, I dont know > how the implementation will get complicated because of this requirement.
Yes, certainly implementable, and I don't think it would complicate the code too much. I alluded to it as a possibility when I first sent out my patches - I think my main issue with it was the fact that it results in multiple container pointers per process at compile time, which could be wasteful. > > This requirement that each process should be exactly in one process container > is perhaps not good, since it will not give the fleixibility to define groups > unique to each resource (see my reply earlier to David Rientjes). I saw your example, but can you give a concrete example of a situation when you might want to do that? For simplicity combined with flexibility, I think I still favour the following model: - all processes are a member of one container - for each resource type, each container is either in the same resource node as its parent or a freshly child node of the parent resource node (determined at container creation time) This is a subset of my more complex model, but it's pretty easy to understand from userspace and to implement in the kernel. > > > the child task is either entirely in the new resource limits or > > entirely in the old limits - if userspace has to update several > > hierarchies at once non-atomically then a freshly forked child could > > end up with a mixture of resource nodes. > > If the user intended to have a common grouping hierarchy for all > resources, then this movement of tasks can be "atomic" as far as user is > concerned, as per the above example: > > echo task_pid > /dev/res_groups/B/members > > should cause the task transition to the new group in one shot? > Yes, if we took that model. But if someone does want to have non-identical hierarchies, then in that model they're still forced into a non-atomic update situation. What objections do you have to David's suggestion hat if you want some processes in a container to be in one resource node and others in another resource node, then you should just subdivide into two containers, such that all processes in a container are in the same set of resource nodes? 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
