On 04/21/2015 06:27 PM, Nathan Scott wrote:
> Hi David,
>
> ----- Original Message -----
>>> ----- Original Message -----
>>>>> [...]
>>>>> Yeah - something like that - have a look at src/libpcp_pmda/src/cache.c
>>>>> as
>>>>> thats how the instance cache number stability is achieved. Perhaps we
>>>>> can
>>>>> extend that with additional APIs to help us out here.
>>>>>
>>>>
>>> Its OK to extend the API/ABI, but not to break it. Which should be all we
>>> need to do here, I think. Maybe see if we can reduce the range that those
>>> cache.c interfaces accept - the two lines with "if (inst == 0x7fffffff) {"
>>> there look promising. If we had a h->maxinst there perhaps, instead of the
>>> hard-coded 2^32-1 limit (may need to change the test to '>=' too) we might
>>> be done and dusted here. That'll turn out to be a gross oversimplification
>>> I'm sure ... but maybe, just maybe it will work.
>>
>> OK, I've been staring at cache.c today, and I've figured out a couple of
>> things.
>>
>> - Most of the existing code is for an instance cache, there doesn't
>> appear to be any existing code for a cluster/metric cache.
>
> A more abstract way to think about it would be 'its a cache for signed 32
> bit identifiers allocated in a monotonically increasing way, allowing for
> holes and with support for optional persistence' ... which we use only for
> instances today.
>
>> - I'm failing to see how changing that 0x07ffffff as you outlined above
>> helps. Can you explain that a bit more?
>
> So, if we can generalise the above a little, we may be able to make it a
> 'cache for identifiers in a range from 0 to some specified maximum, with
> identifiers allocated in a monotonically increasing way, allowing holes
> and optional persistence'.
>
> 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?
>> If you'd like me to add a cluster/metric cache, I'm going to need a bit
>> more explanation about what that will entail.
>
> I don't think that is necessary. I think we may even get away with just
> the one metric identifier cache? (combine cluster and index - using the
> full metric name as the cache key. Maybe? Not sure, but that would help
> with the 1024-metrics-per-source-only problem).
>
>> From a PMDA writer's point of view, I'd think the new APIs would look
>> something like (in pseudo code):
>>
>> - lookup_cluster(domain_id, name)
>> - find_next_available_cluster(domain_id)
>> - lookup_metric(domain_id, cluster_id, name)
>> - find_next_available_metric(domain_id, cluster_id)
>
> 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.
--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
|