pcp
[Top] [All Lists]

Re: [pcp] Proposed updates to cgroup support in the linux_proc PMDA

To: Joseph White <jpwhite4@xxxxxxxxxxx>
Subject: Re: [pcp] Proposed updates to cgroup support in the linux_proc PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 2 Jul 2014 20:17:47 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1293521587.1555994.1404275186280.JavaMail.zimbra@xxxxxxxxxx>
References: <CFD8619A.C63D%jpwhite4@xxxxxxxxxxx> <1293521587.1555994.1404275186280.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: AQHPlU4RoySNyVksN0OJt2/zRcRE1rR0jcxXJD53DQw=
Thread-topic: Proposed updates to cgroup support in the linux_proc PMDA
Hi Joe,

Another thing that occurred to me since sending the earlier reply, a small
thing & it may well be something you already considered...

----- Original Message -----
> ----- Original Message -----
> [...]
> I tend to agree that using an instance domain is the right way to go here.
> The backward compat scenario is of concern, but there are things we can
> do.  One approach would be to use a differently named metric hierarchy, so
> not cgroup.groups.* (which we could drop when we move to the new mechanism
> - the PMAPI provides clear error handling semantics for unavailable metric
> names) - perhaps cgroup.pergroup.* or something like that.
> [...]
> So, we could move to names like cgroup.pergroup.cpuacct "libvirt/lxc::cpu0",
> and cgroup.pergroup.blkio "libvirt/lxc::sda", "::sdb", and so on ...?
> 

Another very appealing aspect here is that we would not need to use dynamic
metrics at all in this PMDA anymore, and a few hundred lines or so of complex
cgroups.c code could be folded back into the static metric table in pmda.c.
This would be a *big* win in code simplicity -- this cgroups code is pretty
obscure & tough to hack on currently; at least, I find it so.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>