lkml.org 
[lkml]   [2004]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Minutes from 5/19 CKRM/PAGG discussion
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@aurema.com
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.600 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site