On 04/14/2015 06:39 PM, Nathan Scott wrote:
> Hi David,
>
> ----- 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.
- I'm failing to see how changing that 0x07ffffff as you outlined above
helps. Can you explain that a bit more?
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.
>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)
--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
|