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 for Android: free password hash cracker in your pocket

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

Message-Id: <1162419813.12419.157.camel@localhost.localdomain>
Date:	Wed, 01 Nov 2006 14:23:33 -0800
From:	Matt Helsley <matthltc@...ibm.com>
To:	David Rientjes <rientjes@...washington.edu>
Cc:	Pavel Emelianov <xemul@...nvz.org>, dev@...nvz.org,
	vatsa@...ibm.com, sekharan@...ibm.com,
	ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
	haveblue@...ibm.com, linux-kernel@...r.kernel.org, pj@....com,
	dipankar@...ibm.com, rohitseth@...gle.com, menage@...gle.com
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

On Wed, 2006-11-01 at 01:53 -0800, David Rientjes wrote:
> On Wed, 1 Nov 2006, Pavel Emelianov wrote:
> 
> > > 	- Interaction of resource controllers, containers and cpusets
> > > 		- Should we support, for instance, creation of resource
> > > 		  groups/containers under a cpuset?
> > > 	- Should we have different groupings for different resources?
> > 
> > I propose to discuss this question as this is the most important
> > now from my point of view.
> > 
> > I believe this can be done, but can't imagine how to use this...
> > 
> 
> I think cpusets, as abstracted away from containers by Paul Menage, simply 
> become a client of the container configfs.  Cpusets would become more of a 
> NUMA-type controller by default.
> 
> Different groupings for different resources was already discussed.  If we 
> use the approach of a single-level "hierarchy" for process containers and 

At least in my mental model the depth of the hierarchy has nothing to do
with different groupings for different resources. They are just separate
hierarchies and where they are mounted does not affect their behavior.

> then attach them each to a "node" of a controller, then the groupings have 
> been achieved.  It's possible to change the network controller of a 
> container or move processes from container to container easily through the 
> filesystem.
> 
> > > 	- Support movement of all threads of a process from one group
> > > 	  to another atomically?
> > 
> > I propose such a solution: if a user asks to move /proc/<pid>
> > then move the whole task with threads.
> > If user asks to move /proc/<pid>/task/<tid> then move just
> > a single thread.
> > 
> > What do you think?
> 
> This seems to use my proposal of using procfs as an abstraction of process 
> containers.  I haven't looked at the implementation details, but it seems 
> like the most appropriate place given what it currently supports.  

I'm not so sure procfs is the right mechanism.

> Naturally it should be an atomic move but I don't think it's the most 
> important detail in terms of efficiency because moving threads should not 
> be such a frequent occurrence anyway.  This begs the question about how 
> forks are handled for processes with regard to the various controllers 
> that could be implemented and whether they should all be decendants of the 
> parent container by default or have the option of spawning a new 
> controller all together.  This would be an attribute of controllers and 

"spawning a new controller"?? Did you mean a new container?

> not containers, however.
> 
> 		David

	I don't follow. You seem to be mixing and separating the terms
"controller" and "container" and it doesn't fit with the uses of those
terms that I'm familiar with.

Cheers,
	-Matt Helsley

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