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

[Srivatsa Vaddagiri]

On Mon, Oct 30, 2006 at 12:47:59PM -0800, Paul Menage wrote:
> On 10/30/06, Paul Jackson <pj@xxxxxxx> wrote:
> >
> >In other words you are recommending delivering a system that internally
> >tracks separate hierarchies for each resource control entity, but where
> >the user can conveniently overlap some of these hierarchies and deal
> >with them as a single hierarchy.
> 
> More or less. More concretely:
> 
> - there is a single hierarchy of process containers
> - each process is a member of exactly one process container
> 
> - for each resource controller, there's a hierarchy of resource "nodes"
> - each process container is associated with exactly one resource node
> of each type
> 
> - by default, the process container hierarchy and the resource node
> hierarchies are isomorphic, but that can be controlled by userspace.

For the case where resource node hierarchy is different from process
container hierarchy, I am trying to make sense of "why do we need to
maintain two hierarchies" - one the actual hierarchy used for resource
control purpose, another the process container hierarchy. What purpose 
does maintaining the process container hierarchy (in addition to the
resource controller hierarchy) solve?

I am thinking we can avoid maintaining these two hierarchies, by 
something on these lines:

	mkdir /dev/cpu
	mount -t container -ocpu container /dev/cpu

		-> Represents a hierarchy for cpu control purpose.

		   tsk->cpurc	= represent the node in the cpu
				  controller hierarchy. Also maintains 
				  resource allocation information for
				  this node.

		   tsk->cpurc->parent = parent node.

	mkdir /dev/mem
	mount -t container -omem container /dev/mem

		-> Represents a hierarchy for mem control purpose.

		   tsk->memrc	= represent the node in the mem
				  controller hierarchy. Also maintains 
				  resource allocation information for
				  this node.

		   tsk->memrc->parent = parent node.


	mkdir /dev/containers
	mount -t container -ocontainer container /dev/container

		-> Represents a (mostly flat?) hierarchy for the real 
	  	   container (virtualization) purpose.

		   tsk->container = represent the node in the container
				    hierarchy. Also maintains relavant 
				    container information for this node.

		   tsk->container->parent = parent node.


I suspect this may simplify the "container" filesystem, since it doesnt
have to track multiple hierarchies at the same time, and improve lock
contention too (modifying the cpu controller hierarchy can take a different 
lock than the mem controller hierarchy).

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