| To: | Marko Myllynen <myllynen@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] Derived metric issues |
| From: | Nathan Scott <nathans@xxxxxxxxxx> |
| Date: | Tue, 9 Feb 2016 16:18:48 -0500 (EST) |
| Cc: | pcp developers <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <56BA4880.1000607@xxxxxxxxxx> |
| References: | <56B99888.2020408@xxxxxxxxxx> <56BA4445.2030404@xxxxxxxxxxxxxxxx> <56BA4880.1000607@xxxxxxxxxx> |
| Reply-to: | Nathan Scott <nathans@xxxxxxxxxx> |
| Thread-index: | pqen675uLJ4N510vL0J4i930SS4kfg== |
| Thread-topic: | Derived metric issues |
----- Original Message ----- > > [...] > > pmRegisterDerived does not apply retrospectively to any open contexts, > > so the normal use would be to make all calls to pmRegisterDerived > > (possibly via pmLoadDerivedConfig(3)) and then call pmNewContext(3). > > A-ha! > > > I'd welcome any suggestions as to how this important piece of > > information could be made more visible. > > After reading the above now it's of course obvious.. Perhaps a short > note in the first section of pmLoadDerivedConfig(3) along the lines > "Note that pmLoadDerivedConfig needs to be called before creating a new > context" or something like that would be enough. > pmReconnectContext(3) can also be used, I believe (that's what the python wrapper uses anyway). cheers. -- Nathan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Queston about pcp performance metrics filesys.used, Frank Ch. Eigler |
|---|---|
| Next by Date: | Re: [pcp] Queston about pcp performance metrics filesys.used, Nathan Scott |
| Previous by Thread: | Re: [pcp] Derived metric issues, Marko Myllynen |
| Next by Thread: | Re: [pcp] Derived metric issues, Marko Myllynen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |