On 21/01/15 12:31, Frank Ch. Eigler wrote:
...
BTW, I'm starting an effort to drastically -reduce- the usage of
pmdaCache stuff in pmdas/linux_proc, in hope of solving problems such as
https://bugzilla.redhat.com/show_bug.cgi?id=1065803
and http://oss.sgi.com/bugzilla/show_bug.cgi?id=1102
and http://oss.sgi.com/pipermail/pcp/2014-November/005989.html
I quickly looked at these issues, but from the info there I don't see a
smoking gun pointing at pmdaCache ... not sayting it is not implicated,
just not obvious to me.
IMHO the cache should be used for only long-lasting invariant-preserving
things like some instance-domains, instead as a general "lookup table for
stuff", with ill-defined scope and lifespan and access control.
I humbly disagree 100%. pmdaCache can be used very effectively to
support mapping between PCP acceptable instance names and identifiers
and external names/uuids, etc -- exactly the "lookup table sort of stuff".
If the mapping is not long-lasting and invariant, this means don't
persist the cache (don't call pmdaCacheOp with the options
PMDA_CACHE_SAVE and PMDA_CACHE_LOAD), but using a dynamic (rebuilt each
time) cache using pmdaCache may be just fine.
In all of this we need to keep remembering the PCP semantic assumptions
about instance domains:
1. If an external object (CPU, filesystem, disk, ...) persists over time
and has the same external designation, e.g. cpu0, /usr, sdc, then the
PMDA should return the same internal instance id and external instance name.
2. External instance names have to be unique up to the first space.
3. Internal instance ids have to be unique in the range 0 to 2^31-1
Note that if the external object has a constant name, like sdc but the
kernel gives it a dynamic id (like a scsi id) then this is _exactly_ the
case the pmdaCache will work well for (the instance name <--> id mapping
is in the cache and the kernel's id is stashed away via the opaque
"private" handle to the store and lookup methods.
|