Re: Minutes from 5/19 CKRM/PAGG discussion

[Hubertus Franke <frankeh@watson.ibm.com>]

Rik van Riel wrote:

>On Mon, 24 May 2004, Hanna Linder wrote:
>
>  
>
>>Minutes from LSE call on CKRM and PAGG on May 19, 2004. 
>>    
>>
>
>Thanks for organising this call, Hanna!
>
Thanks 2.. sorry I couldn't make it ...

>
>  
>
>>Conclusion:
>>
>>	CSA/PAGG look at CKRM 
>>	CKRM look at PAGG
>>    
>>
>
>I really hope the projects will be able to agree on one
>framework.  As long as there are multiple competing
>frameworks the chance of any of them being merged into
>the upstream kernel is exceedingly low...
>
>  
>
Agreed, so let's get the ball rolling.

We (CKRM team) will look at PAGG (again) ... Actually we did
last year and basically assumed due to the inactivity that
PAGG was not actively persued anymore.

I believe at our end we will come to the conclusion that CKRM can serve
as the base for CSA, as PAGG seems to be lowest level layer of
this management silo. The level CSA would hook to is that of
the CKRM event hooking which is part of the CKRM core.

One important input the PAGG team could give is some real
examples where actually multiple associations to different groups
is required and help us appreciate that position and let us
see how this would/could be done in CKRM.

 From our point of view we don't see this requirement. In contrast
we use the modified rbce (CRBCE) to push the "interesting" kernel events
to userspace where any kind of accounting aggregation can take place.
Yet, we believe the integrated resource scheduling (e.g. cpu) will
always happen at the dominant class - object association in the kernel.

Another point that has not been made is that CKRM's philosophy
is to manage any kind of objects wrt to some class type.
By definition, PAGG is a Process Aggregation, which is a subset
of what CKRM needs namely (obj->class) associations.

In our hooking scheme we therefore provide the ability to attach
to so called kernel events a callback function. Any kernel code
can attach a callback function. This is part of our core.

Any classtype (not part of the core) can register a callback at
any of those events, so typically only limited
events are "hooked" for a particular type. Regardless, we have
function stacking, rather then object stacking.

PAGG by itself manages the proper association of a (or several)
"transparent" group object with the task. The functionality
hidden behind the group object
still needs to be implemented by the group object itself.

In CKRM this is similar, yet, the class object is associated with
a particular class type. All interactions with the user component
and classification engine are architected by the higher layers of CKRM,
in that classes have automatic representation in RCFS and RBCE if
those are loaded.

So here are some of the stickling points, we need to work on ...

(a) how can PAGG be made general enough so we can provide generic
       KernelObject <-> ClassObject associations .. not just tasks groups.

(b) Can CSA use the extended rbce (CRBCE) instead of PAGG to
       do its accounting ?

-- Hubertus Franke