Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

[Srivatsa Vaddagiri]

On Tue, Oct 31, 2006 at 08:39:27PM -0800, David Rientjes wrote:
> So here's our three process containers, A, B, and C, with our tasks m-t:
> 
> 	-----A-----	-----B-----	-----C-----
> 	|    |    |     |    |    |     |    |
> 	m    n    o	p    q    r	s    t
> 
> Here's our memory controller groups D and E and our containers set within 
> them:
> 
> 	-----D-----	-----E-----
> 	|         |	|
> 	A         B	C

This would forces all tasks in container A to belong to the same mem/io ctlr 
groups. What if that is not desired? How would we achieve something like
this:

	tasks (m) should belong to mem ctlr group D,
	tasks (n, o) should belong to mem ctlr group E
  	tasks (m, n, o) should belong to i/o ctlr group G

(this example breaks the required condition/assumption that a task belong to 
exactly only one process container).

Is this a unrealistic requirement? I suspect not and should give this
flexibilty, if we ever have to support task-grouping that is
unique to each resource. Fundamentally process grouping exists because
of various resource and not otherwise.

At this point, what purpose does having/exposing-to-user the generic process 
container abstraction A, B and C achieve?

IMHO what is more practical is to let res ctlr groups (like D, E, F, G)
be comprised of individual tasks (rather than containers). 

Note that all this is not saying that Paul Menages's patches are
pointless. In fact his generalization of cpusets to achieve process
grouping is indeed a good idea. I am only saying that his mechanism
should be used to define groups-of-tasks under each resource, rather
than to have groups-of-containers under each resource.


-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/