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

[Shailabh <nagar@watson.ibm.com>]

Guillaume Thouvenin wrote:
> Selon Christoph Hellwig <hch@infradead.org>:
> 
> 
>>>I suspect there's a rather good chance of merging a common
>>>PAGG/CKRM infrastructure, since they pretty much do the same
>>>thing at the core and they both have different functionality
>>>implemented on top of the core process grouping.
>>
>>Still doesn't make a lot of sense.  CKRM is a huge cludgy beast poking
>>everywhere while PAGG is a really small layer to allow kernel modules
>>keeping per-process state.  If CKRM gets merged at all (and the current
>>looks far to horrible and the gains are rather unclear) it should layer
>>ontop of something like PAGG for the functionality covered by it.
> 
> 
> And what about put the management of containers outside the kernel. We could for
> exemple use a program that will listen file /proc/acct_event and execute a
> programs to handle the event like ACPID does. Of course it will need some kernel
> modifications but those modifications will be small as process aggregation will
> be done outside the kernel. We could also use relayfs to exchange datas between
> user program and the kernel.
> 
> Guillaume


Guillaume,

As mentioned in my response to Christoph, keeping process aggregation 
outside the kernel (or as a module that sits atop process-centric 
patches) will work only for statistics gathering and coarse-grain 
control.

CKRM's crbce controller (will be put up on http://ckrm.sf.net within a 
day...) uses relayfs to send per-process data to a privileged user 
program (will also be included) that can use the data as it pleases, 
including doing aggregation.

We think a class-aware kernel is the right way to go and it can be 
done with sufficiently low impact that one doesn't have to 
unnecessarily limit the flexibility of users in defining process 
groups (=classes) or the time periods over which shares can be enforced.

-- Shailabh