lkml.org 
[lkml]   [2004]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Lse-tech] Re: Minutes from 5/19 CKRM/PAGG discussion
Hubertus Franke wrote:
> Peter Williams wrote:
>
>> Hubertus Franke wrote:
>>
>>>
>>> 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.
>>
>>
>>
>> One example would be the implementation of CPU sets (or pools) a la
>> Solaris where there are named CPU pools to which processors and
>> processes are assigned. Processors can be moved between CPU pools
>> and when this happens it is necessary to visit all the processes that
>> are assigned to the pools involved (one losing and one gaining the
>> processor) and change their CPU affinity masks to reflect the new
>> assignment of processors. PAGG would be ideal for implementing this.
>>
>> At the same time, a resource management client could be controlling
>> resources allocated to processes based on some other criteria such as
>> the real user or the application being run without regard to which CPU
>> pool they are running in.
>>
>> Peter
>
>
> Good one, at question though is again though is whether the very
> communalities warrant some realignment. We want to hook into the base
> schedulers and be the clearing house or umbrella to consolidate all the
> ideas, such as the well defined RCFS recently introduced together with
> Rik van Riel. PAGG is as stated a way of doing things outside the core
> kernel and hookable schedulers have been several times rejected at the
> lkml base.

PAGG does not provide any control capabilities and anyone who wished to
use PAGG for control would have to use existing control interfaces. So
this argument does not apply.

>
> One potential is to agree that the communalities are so few that it
> makes sense to continue with both approaches independently.
>

I don't think that it's that bad. The problem is that CKRM (which is
huge) wants to do everything itself (and its way). In reality, CKRM
needs a lot of lower level features that don't currently exist and many
of these features have merit in their own right independent of CKRM's
need for them. These lower level features should be separated out from
CKRM and presented as the (potentially) small and easy to understand
mechanisms that they are. Other developers would then be free to use
these mechanisms as they see fit (probably using them for innovative
things not envisaged by any of us). To fully realize their potential
these features need to (where it's sensible) support multiple
simultaneous clients and be as efficient and easy to use as possible
(and some of the ideas present in PAGG would help in this regard).

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.220 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site