Hi -
> You're also ignoring the problem of how to sensibly handle PAPI_ECNFLCT,
No. In fact, because we'd be adding events to the eventset one at a
time (upon request of individual fetches), we can produce proper
incremental diagnostics for them. Whereas you were suggesting a
pmstore with multiple event names encoded into a string, where in case
of a PAPI_ECNFLCT or other error, a user can't tell which part was
wrong.
> And that pmstore is the only sensible mechanism to support a PAPI_reset.
Why do you think a PAPI_reset is per se desirable? What pcp client
would prefer to be subjected to another pcp client's discontinuity
whimsy?
> The fine-grained control offered by using pmstore will also help greatly
> when writing automated QA, and for attempting to diagnose PMDA problems.
I see no qa-worthy difference between a pmstore vs. a pmprobe to the
same metric.
> > - tooling support, so i.e., it can't be used for reliable logging
> > as pmlogger is not in the business of pmstore'ing constantly
>
> ("constantly" seems misplaced there, can you explain what you meant?)
pmlogger would have to resend the pmstore whenever the remote pmcd
suffered a disconnect / restart.
> But the tooling support needs to be fixed independently, anyway, for
> all the other cases where folks use pmstore, and is highly desirable
> for general server-side filtering (for PM_TYPE_EVENT metrics).
We do not need to hang that hardly-relevant burden on this piece of work.
> > isolation of users/apps from each other,
> > and from state-losing upsets like pmcd restarts
>
> Disagree on those - these issues are present in both approaches, and
> the same sorts of approaches can be used to resolve them.
No. With the automatic model, different users cannot interfere with
each other (subject to sampling error induced by multiplexing). With
the pmstore model, only a single concurrent user of the pmda is
possible, since you're expecting each to initialize / use / teardown
their entire set of counters.
If in an alternative pmstore-based model, if the counter sets are to
be manipulated incrementally (add/remove counters rather than
select-entire-set), then you have almost exactly the same code
complexity I outlined -- for that's roughly what it takes to modify a
running papi eventset and not lose partial counts. And you still have
the interference problem (someone tearing down an experiment, shutting
down counters that others were still using).
> [...]
> Except for the bits at the end which use pmstore ;)
... which was specifically noted as being for old-schoolers only, and
in no way necessary for it to work.
> > automatic activation of papi counters.
> > [...]
>
> Wow, that is so incredibly complex.
It may look that way, but perhaps degree of worked-out detail is
mistaken for increased complexity compared to a less worked out
alternative.
> How on earth did we get from multiplexing being "just one line of
> code" on IRC yesterday to this? [...]
Multiplexing is an orthogonal issue to pcp-level activation model.
- FChE
|