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
-
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]
