Re: Minutes from 5/19 CKRM/PAGG discussion

[Peter Williams]

Hubertus Franke wrote:
> Peter Williams 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.
> >
> >
> >
> > Additionally, it seems to me that even within the field of resource 
> > management it is not necessarily the case that the same grouping is 
> > required for different resource types e.g. the grouping for control of 
> > CPU resources might be different to the grouping for control of 
> > network bandwidth allocation or disk space or disk I/O bandwidth, etc.
> >
> > Peter
>
>
> Correct, that is in principle possible. We went through this discussion 
> on the mailing list  .. (Rik, Shailabh help me out here) and decided 
> that mostly that is

Mostly isn't good enough :-)

> not being required. The extra overhead of putting that we deemed 
> unnecessary.

I think that this would be minimal.

> Instead, if really desired, one would require a different classtype for 
> each of those groupings. Note however, our entire infrastructure already 
> supports that in that RCFS would pick these specialized class types up, 
> provide the proper hierarchy as an FS subdirectory structure. For us it 
> was mainly a question how we can get the most out of the initial 
> prototype without having general users have to go and specify all kinds 
> of hierarchies, i.e. one per resource.

If that is what you want (and it's not an unreasonable desire) there is 
nothing to stop CKRM from imposing this view of the world on top but you 
shouldn't be forcing this view on others.  I.e. it's easy to consolidate 
separate grouping mechanisms to have a common grouping for all 
KernelObjects but it would be very close to impossible to try to present 
separate groupings for each KernelObject if there was only one 
underlying grouping.

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/