Re: Minutes from 5/19 CKRM/PAGG discussion

[Hubertus Franke]

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
not being required. The extra overhead of putting that we deemed 
unnecessary.

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.

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