lkml.org 
[lkml]   [2006]   [Nov]   [1]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 1 Nov 2006 15:37:12 -0800
From"Paul Menage" <>
SubjectRe: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
On 11/1/06, Srivatsa Vaddagiri <vatsa@in.ibm.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-11-02 00:41    [from the cache]
©2003-2008