On 04/28/2015 09:30 AM, David Smith wrote:
> 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.
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.
--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
|