Guillaume writes:
> Is it be possible to split PAGG into two pieces:
> 1. The container manager part
> 2. The hook manager part
But the "container manager" is simply the projection of the hook manager
onto the set of tasks <grin>.
In other, less obfuscated terms, I mean that two tasks are in the same
"container" iff they have the same hooks. So with the current
implementation, I doubt they split. We have two ways of looking at one
mechanism, not two mechanisms.
Or at least, that's my understanding of PAGG (I could easily be mistaken
here - beware).
I could see some refactoring being of benefit here, however.
I'd be tempted to consider, if these were my projects:
1) Implementing the 'container manager' using a simple
integer id field in the task struct, some sort of "job id"
(jid), with associated getjid system call, similar to
gettid and getpid, and "Jid: <jid>" /proc/*/status field.
2) Continuing to work with the others doing system accounting
data collection to integrate CSA, as I see others already doing.
3) For any resource management aspects, work with CKRM.
The hook manager is an implementation intended to support loadable
kernel modules doing some of this work. I will be surprised if these
can be done this way, and do not share the enthusiasm of my SGI
colleagues for this mechanism.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.650.933.1373, 1.925.600.0401
|