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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
