Re: Minutes from 5/19 CKRM/PAGG discussion

[Peter Williams]

Hubertus Franke wrote:
> Peter Williams wrote:
> > 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.

I think that you are looking at this issue too much from a CKRM point of 
view.  I.e. just because CKRM doesn't need it doesn't mean that it isn't 
 a good idea.  In fact the issue should be viewed more broadly than 
just a "resource management" point of view.

If there are multiple clients then having their per KernelObject data 
managed using the PAGG mechanism greatly simplifies the task of 
implementing a client AND reduces the potential overhead on the system 
as the alternative is for the client to use some type of search 
mechanism to find its copy of its per KernelObject specific data when 
servicing its callback functions.

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

I think that this is just a detail and that what should happen is that a 
PAGG like mechanism be applied to sockets.  Similarly, to enable memory 
management/monitoring one attached to address space structures would be 
useful.  And so on.

> Hence we need our generic infrastructure at the core 
> level. Sure we can try to modularize further to take the CKRM EVENTS 
> out.

I think that breaking these up into smaller chunks (based on the type of 
KernelObject to which they apply) would be a good idea.  The fact that 
CKRM wants to use them all isn't sufficient justification to lump them 
all together.

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

I think that this is another example of you taking a too CKRM centric 
point of view.  What I'm trying to say is that I think that these lower 
level interfaces need to be more independent of CKRM's requirements.

Peter
--
Dr Peter Williams, Chief Scientist                peterw@xxxxxxxxxx
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com

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