Date:	Thu, 3 Aug 2006 22:36:50 -0700
From:	Andrew Morton <akpm@...l.org>
To:	vatsa@...ibm.com
Cc:	mingo@...e.hu, nickpiggin@...oo.com.au, sam@...ain.net,
	linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de,
	balbir@...ibm.com, sekharan@...ibm.com, nagar@...son.ibm.com,
	haveblue@...ibm.com, pj@....com
Subject: Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu
 controller

On Fri, 4 Aug 2006 10:37:53 +0530
Srivatsa Vaddagiri <vatsa@...ibm.com> wrote:

> Resource management has been talked about quite extensively in the
> past, more recently in the context of containers. The basic requirement
> here is to provide isolation between *groups* of task wrt their use
> of various resources like CPU, Memory, I/O bandwidth, open file-descriptors etc.
> 
> Different maintainers have however expressed different opinions over the need to
> complicate the kernel to meet this need, especially since it involves core 
> kernel code like the resource schedulers. 
> 
> A BoF was hence held at OLS this year to come to a consensus on the minimum 
> requirements of a resource management solution for Linux kernel. Some notes 
> taken at the BoF are posted here:
> 
> 	http://www.uwsg.indiana.edu/hypermail/linux/kernel/0607.3/0896.html
> 
> An important consensus point of the BoF seemed to be "focus on real 
> controllers more, preferably memory first, using some simple interface
> and task grouping mechanism".

ug, I didn't know this.  Had I been there (sorry) I'd have disagreed with
this whole strategy.

I thought the most recently posted CKRM core was a fine piece of code.  It
provides the machinery for grouping tasks together and the machinery for
establishing and viewing those groupings via configfs, and other such
common functionality.  My 20-minute impression was that this code was an
easy merge and it was just awaiting some useful controllers to come along.

And now we've dumped the good infrastructure and instead we've contentrated
on the controller, wired up via some imaginative ab^H^Hreuse of the cpuset
layer.

I wonder how many of the consensus-makers were familiar with the
contemporary CKRM core?

> In going forward, following points will need to be addressed:
> 
> 	- Grouping and interface
> 		- What mechanism to use for grouping tasks and
> 		  for specifying task-group resource usage limits?

ckrm ;)

> 	- Design of individual resource controllers like memory and cpu

Right.  We won't be controlling memory, numtasks, disk, network etc
controllers via cpusets, will we?


> This patch series is an attempt to take forward the design discussion of a
> CPU controller.

That's good.  The controllers are the sticking point.  Most especially the
memory controller.

> For simplicity and convenience, cpuset has been chosen as the means to group 
> tasks here, primarily because cpuset already exists in the kernel and also 
> perhaps resource container definition should be unique only inside a cpuset.
> 

Correct me if I'm wrong, but a cpuset isn't the appropriate machinery to be
using to group tasks.

And if this whole resource-control effort is to end up being successful, it
should have as core infrastructure a flexible, appropriate and uniform way
of grouping tasks together and of getting data into and out of those
aggregates.  We already have that, don't we?



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

Powered by blists - more mailing lists