Re: Minutes from 5/19 CKRM/PAGG discussion

[Hubertus Franke]

Peter Williams wrote:

> Hubertus Franke wrote:
>
> > 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.
>
>
> I'm assuming that this means several clients can use the same callback 
> simultaneously?

Yes it means exactly that ....

> > 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.
>
>
> I would suggest that rather than extending PAGG, separate mechanisms 
> similar in design to PAGG be created for each KernelObject for which 
> such associations are required.  Perhaps the generic component of such 
> mechanisms could be separated out into a generic package and then each 
> specific mechanism just provides the specialization for its 
> KernelObject type.  I'd imagine that the main difference between the 
> specialized packages would be (apart from the different type of 
> KernelObject) in the set of callbacks provided.
Yes, and that has been done. Currently we have two such classtype  
(class task and network class) both supplied as independent "modules" 
atop the ckrm core.
And you are right again wrt the difference aspect. Each class registers 
the callbacks its interested in.

> > (b) Can CSA use the extended rbce (CRBCE) instead of PAGG to
> >       do its accounting ?
>
>
> From my (possibly incorrect) understanding of the above description, 
> one thing that PAGG provides to its clients that CKRM doesn't is the 
> ability to attach some private data to task structs and it passes that 
> data to the client as part of the callback.  Am I correct in this 
> interpretation?
>
> Peter

That is the "stickling" point. Yes, PAGG provides this feature that one 
can chain private data to the attach/detach callback. CKRM at this point 
does not do that as we do not see the need for multiple class 
associations in the core. Instead we can drive such things through the 
extended RBCE interface. Here you register callbacks to the task 
classtype to be notified of the ckrm events.

Since we do networking, PAGG is not sufficient for us as it only deals 
with processes. Hence we need our generic infrastructure at the core 
level. Sure we can try to modularize further to take the CKRM EVENTS 
out. Then potentially one could implement task types on top of PAGG on 
top of CKRM Events (which are needed anyway for other the task class 
associations), but then again PAGG brings nothing but another indirections.

It worthwhile to consider to bite the bullet and allow PAGG to enter its 
task class association chain (1 word) and allow CKRM its own. CKRM is 
going after the integrated resource schedulers, PAGG/CSA (afaik) does not.

-- Hubertus

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