On 10/3/06, Chandra Seetharaman <[EMAIL PROTECTED]> wrote: > > Hi Paul, > > Thanks for doing the exercise of removing the container part of cpuset > to provide some process aggregation. > > With this model, I think I agree with you that RG can be split into > individual controllers (need to look at it closely). > > I have few questions/concerns w.r.t this implementation: > > - Since we are re-implementing anyways, why not use configfs instead of > having our own filesystem ?
The filesystem was lifted straight from cpuset.c, and hence isn't a reimplementation, it's a migration of code already in the tree. Wasn't there also a problem with the maximum output size of a configfs file, which would cause problems e.g. listing the task members in a container? > - I am little nervous about notify_on_release, as RG would want > classes/RGs to be available even when there are no tasks or sub- > classes. (Documentation says that the user level program can rmdir > the container, which would be a problem). Can the user level program > be _not_ called when there are other subsystems registered ? Also, > shouldn't it be cpuset specific, instead of global ? This again is taken straight from cpusets. The idea is that if you don't have some kind of middleware polling the container/cpuset/res_group directories to see if they're empty, you can instead ask the kernel to call you back (via "container_release_agent") at a point when a container is empty and hence removable. I don't think there's any guarantee that the container will still be empty by the time the userspace agent runs. > - Export of the locks: These locks protect container data structures. > But, most of the usages in cpuset.c are to protect the cpuset data > structure itself. Shouldn't the cpuset subsystem have its own locks ? > IMO, these locks should be used by subsystem only when they want data > integrity in the container data structure itself (like walking thru > the sibling list). It would certainly be possible to have finer-grained locking. But the cpuset code seems pretty happy with coarse-grained locking (only one writer at any one time) and having just the two global locks does make the whole synchronization an awful lot simpler. There's nothing to stop you having additional analogues of the callback_mutex to protect specific data in a particular resource controller's private data. My inclination would be to find a situation where generic fine-grained locking is really required before forcing it on all container subsystems. The locking model in RG is certainly finer-grained than in cpusets, but don't a lot of the operations end up taking the root_group->group_lock anyway as their first action? > - Tight coupling of subsystems: I like your idea (you mentioned in a > reply to the previous thread) of having an array of containers in task > structure than the current implementation. Can you suggest some scenarios that require this? Paul ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
