Re: [PATCH] Process Aggregates (PAGG) support for the 2.6 kernel

[Shailabh]

Chris Mason wrote:
> On Fri, 2004-04-30 at 09:06, Christoph Hellwig wrote:
>
> > On Fri, Apr 30, 2004 at 08:54:08AM -0400, Rik van Riel wrote:
> >
> > > What was the last time you looked at the CKRM source?
> >
> > the day before yesterday (the patch in SuSE's tree because there
> > doesn't seem to be any official patch on their website)

That was rectified concommitant with the lkml posting of the patches
for ckrm-E12. Please see the Implementation section of 
http://ckrm.sf.net for all the current patches.
	

> >
>
> Somewhat unrelated, but the day before yesterday suse was at ckrm-e5,
> we're now at ckrm-e12.

Good point. One of the major changes between ckrm-e5 and ckrm-e12 is a
serious attempt at modularizing and cleaning up the internal 
interfaces which should help allay concerns about it being a big piece 
of code which has to be taken in whole.



From the view of kernel developers considering merging CKRM into the
kernel, only two components are essential:

core
rcfs

Of course, to do anything useful, you need to have either one of

task_class: groups tasks together
socket_class: groups sockets together

the two are completely independent.

Once a particular grouping is chosen, one can further selectively 
include one or more resource controllers associated with the grouping.
i.e. for task_classes, choose one or more of cpu, mem, io, 
numtasks....; for socket_class, choose one or more of listenaq,<future 
socket based controllers, potentially including outbound network 
control)....


The same kind of flexibility that is available to kernel developers 
for integrating parts of ckrm selectively, will also remain available 
to users, even if all of CKRM is included. So a user could enable just 
task_classes and the cpu controller if s/he doesn't care about memory, 
io or any other kind of control.



-- Shailabh




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