On 07/08/14 09:37, Nathan Scott wrote:
Hi Ken,
...
This subtree is populated when cgroup subsystems exist - I guess these
are older kernels with no cgroups? (hmm I wonder if this is the right
error code for this situation?).
Well the problem is appearing on a (newer) 3.2.0 Debian kernel, but not
on an (older) 3.13.0 Ubuntu kernel ... so there must be some other magic
controlling this.
3.2.0 system
kenj@bozo-vm:~$ cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
cpuset 0 1 1
cpu 0 1 1
cpuacct 0 1 1
memory 0 1 0
devices 0 1 1
freezer 0 1 1
net_cls 0 1 1
blkio 0 1 1
perf_event 0 1 1
3.13.0 system
kenj@bozo:~/src/pcp$ cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
cpuset 2 21 1
cpu 3 21 1
cpuacct 4 21 1
memory 5 9 1
devices 6 9 1
freezer 7 9 1
blkio 8 9 1
perf_event 9 9 1
hugetlb 10 4 1
One part of the last round of changes was to make cgroup.groups. the
dynamic non-leaf PMNS entry, whereas previously it was cgroup. - and
that was *always* populated with the cgroup.mounts and cgroup.subsys
(fixed) hierarchies. Could be some latent issue with dynamic names?
Or maybe I've just (ab)used them in a new way.
I think this is a semantic corner case ... the PM_ERR_NAME error is
probably the most appropriate (indeed if you did not set it in the PMDA,
the libpcp_pmda routines would set it to that value when the PMNS at the
dynamic node is NULL).
I notice mmv always does this "pre-populate with a few fixed names"
for its dynamic namespace use, and the Linux kernel interrupt names
(also dynamic) will always have a starting set... hmmm.
This approach allows the dynamic node to always have something as a
descendent in the PMNS and avoids the problem I've seen, but it is not
required.
So, back to my original question, is there some easy way to force
population of the cgroup.groups in the PMNS for QA purposes?
|