linux-kernel - Re: [ckrm-tech] [RFC] Resource Management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061101155937.GA2928@in.ibm.com>
Date:	Wed, 1 Nov 2006 21:29:37 +0530
From:	Srivatsa Vaddagiri <vatsa@...ibm.com>
To:	David Rientjes <rientjes@...washington.edu>
Cc:	Paul Menage <menage@...gle.com>, Paul Jackson <pj@....com>,
	dev@...nvz.org, sekharan@...ibm.com,
	ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
	haveblue@...ibm.com, linux-kernel@...r.kernel.org,
	matthltc@...ibm.com, dipankar@...ibm.com, rohitseth@...gle.com
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/