pcp
[Top] [All Lists]

Re: [pcp] JSON PMDA

To: David Smith <dsmith@xxxxxxxxxx>
Subject: Re: [pcp] JSON PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 28 Apr 2015 19:02:02 -0400 (EDT)
Cc: pcp <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <553FE622.4030002@xxxxxxxxxx>
References: <54F9F92D.4010202@xxxxxxxxxx> <2139482617.15593599.1428634701360.JavaMail.zimbra@xxxxxxxxxx> <552D6524.1030803@xxxxxxxxxx> <1237712965.18667183.1429054767135.JavaMail.zimbra@xxxxxxxxxx> <5536C228.8010001@xxxxxxxxxx> <1344441557.4430503.1429658863072.JavaMail.zimbra@xxxxxxxxxx> <553F9968.4070509@xxxxxxxxxx> <553FE622.4030002@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: vP6y+l1YztpFYaRQAg9POyYNEK323A==
Thread-topic: JSON PMDA
Hi David,

----- Original Message -----
> On 04/28/2015 09:30 AM, David Smith wrote:
> >> The pmInDom is a domain number (JSON 137) and a "serial" number.  So in
> >> our situation here, we could reserve serial #0 for a metric-identifier
> >> cache, #1 for an indom-identifier cache, and then use the rest of the
> >> space for indom-instance caches.
> > 
> > Wouldn't it make more sense to reserve serial #0 for the indom-instance
> > cache, since that is what serial #0 is current used for (in effect)? How
> > much is the current indom-instance cache used today?

Sure.  By "reserved" we are meaning within pmdajson right? (not libpcp_pmda)
The current pmdaCache routines are used extensively by other PMDAs, so care
must be taken not to introduce new restrictions there.

> >> As per the earlier mail with kenj (re ioctl), I think the only new API we
> >> will need for this aspect would be something like:
> >>
> >> int pmdaCacheResize(pmInDom indom, int maximum);
> >>
> >> the rest of the pmdaCacheOp(3) interfaces should give us the rest of the
> >> cache manipulation functionality you need (like persisting, restoring, &
> >> so on).
> > 
> > I wonder if it wouldn't make sense to define something like the
> > following instead:
> > 
> >     int pmdaCacheOp2(pmInDom indom, int op, unsigned long val);
> > 
> > with an associated op of PMDA_CACHE2_RESIZE. That would give more room
> > for the addition of future operations.

I prefer the Linux kernel attitude myself - shy away from ioctl whenever
possible, and use unambiguous, well-defined APIs.  There's a clear path
for us to introduce additional APIs later if needed, just as we are now.

> Thinking about this a bit more, are you thinking the serial # to XXXX
> item cache is just a suggestion or will we be hard-coding those
> assignments? If we hard-code those assignments, then do we even need
> pmdaCacheResize()? Based on the serial #, we would then know what the
> maximum number of the associated items would be.

Hard-coded in pmdajson, not libpcp_pmda - so some mechanism to tell the
library a limit for an individual cache will be needed.  There are other
PMDAs that will want to opt-in to using this too, and they'll have their
own size limits for specified (new) pmda-local indoms too (and different
requirements about the indom# - e.g. they may already be using serial#
zero and one).

cheers.

--
Nathan

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