Hi Martins,
----- Original Message -----
> Nathan,
>
> On 5/11/14 10:35 PM, Nathan Scott wrote:
> > [...]
> > On Linux, the cgroup concept could provide a more flexible mechanism. The
> > kernel support means the "hot process" evaluation side of things becomes
> > optional (IOW, one could deem processes worthy of logging or whatever-one-
> > would-otherwise-use-hotproc-metrics-for simply by ensuring the processes
> > to be monitored start in a specific cgroup, using existing cgroup tools.
> > Which, for some potential use-cases, is a big win cos walking the complete
> > list of processes can be prohibitively expensive, for very large process
> > counts. A handy mechanism for obtaining only the processes in a specific
> > cgroup is provided by the kernel already, and the Linux pmdaproc already
> > knows how to use it.
>
> I'm not too familiar with actually modifying cgroups, but we use them
> here extensively with various software that supports them natively:
> slurm, various MPIs, etc. I had not thought about using cgroups to
> manage a set of hotprocs. As I've started to look into this, its not
> clear to me if moving processes around between cgroups would break these
> existing tools. Slurm for instance, starts in a cgroup, and then spawns
> tasks which then live under that same hierarchy. If one, but not all,
> of these new processes becomes "hot", I can imagine that there would be
> some ramifications to moving it to a different cgroup, without its
> siblings, parent, etc. This will require some testing. Let me know if
> i've misunderstood or if you have thoughts on this.
Oh, absolutely - I would also tend to think moving between cgroups would
cause widespread issues. AIUI, processes can belong to multiple cgroups
however - so, instead of *moving* from existing group(s) into a new group
I think we should have an additional pcp group, into which process can be
dynamically added/removed - orthogonal to any/all other cgroups they are
in already. Then pmlogger and other clients could make use of the proc
metrics, as-is, which would be a pre-filtered set of processes.
> [...]
> Right. My goal in all this was to try to get it into one pmda.
Cool, provided my "AIUI" statement above is correct :) - cgroups seem to
offer a very effective (code-wise), & very efficient, path to this goal.
cheers.
--
Nathan
|