----- Original Message -----
> Hi,
>
> I think I have a pretty good version of the dynamic proc metrics implemented
> as they relate to anything with a PID instance. My tree is here:
>
> https://github.com/ubccr/pcp/tree/dynamic_proc
Great, thanks Martins. I've started using this code as the base for that
cgroups metric rework too.
> If this all looks generally ok, I'll submit my hotprocs changes on top of
> this.
Yes please.
> I modeled it on the basic structure of linux/interrupts.c. A couple
> things:
>
> 1. I ran the existing QA tests (./check -g pmda.proc) and everything seemed
> to be OK, except for the ordering of the metrics in 022 and 943. I don't
> think this can be fixed since it would mean some non-dynamic metrics would
> have to come in the middle. Let me know if there is a way/desire to fix the
> ordering.
I have a fix for 022 & will do 943 - they're fixable using sort(1) to produce
deterministic output.
I'm also seeing 580 fail, looks probably related:
$ diff 580.out 580.out.bad
7,9c7
< pm*InDom: inst=[1] iname=<ONE init> reverse lookup: inst=[1]
< pmGetInDom:
< [1] <ONE init>
---
> Error: Unknown or illegal metric identifier
I'll dig into it later in the week if its not failing elsewhere and/or not
reproducible.
> 2. I needed to use pmdaTreeRebuildHash while the interrupts code didn't. Joe
> pointed out that this is likely due to that fact that the linux pmda runs as
> a dso and proc does not. So there may be some other code that handles the
> dso case differently. I couldn't find this documented anywhere.
Yeah, thats like it - pmcd will do it (internally via libpcp) and that is
probably fixing things up by luck for those interrupt metrics too.
> 3. Couldn't find any precedent for handling long form help text for dynamic
> pmdas. So I just generated a header file from the existing help file and
> used that. Let me know if you want something different. Attached is the perl
> script I wrote for that in case it is generally useful.
We might be able to do some remapping from hotproc -> proc variants, but I
don't think there's any precedence there I can point you towards - I'll can
take a look into that too if you like.
> 4. I left a few commented code sections that will show where hotprocs will
> hook in. Will add another root node, and all other stuff ( help, etc ) will
> be shared.
Perfect.
> If this looks ok, it will probably take another day to update hotprocs. Let
> me know if there is anything that looks wrong or needs to be changed.
Its looking good to me, thanks Martins!
cheers.
--
Nathan
|