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