pcp
[Top] [All Lists]

Re: PCP papi PMDA

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: PCP papi PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 3 Jul 2014 18:20:19 -0400 (EDT)
Cc: Lukas Berk <lberk@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0megy2y2c1.fsf@xxxxxxxx>
References: <20140625024307.GA9275@xxxxxxxxxx> <2109769793.33209354.1403680688562.JavaMail.zimbra@xxxxxxxxxx> <13003259.2530950.1404361308252.JavaMail.zimbra@xxxxxxxxxx> <y0megy2y2c1.fsf@xxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 9jd1bEQOKWWzhah40OwtyyrK8zXZfA==
Thread-topic: PCP papi PMDA
Hi Frank,

----- Original Message -----
> > 2. enabling counters
> > [...]
> > Initially, lets keep it simple.  There has been some doubt expressed
> > whether the auto-enabling will actually work with good error-handling
> > semantics - noones ever done this before - and it doesn't function at
> > all for short-lived PMAPI clients (*) - see example below.
> 
> That's not entirely correct.

It's correct, based on the code that is there.  The timeout approach is
a hack IMO and your outlined approach looks pretty complex to me, so
again, lets start simple and build up please.

You're also ignoring the problem of how to sensibly handle PAPI_ECNFLCT,
and that pmstore is the only sensible mechanism to support a PAPI_reset.
The fine-grained control offered by using pmstore will also help greatly
when writing automated QA, and for attempting to diagnose PMDA problems.

It occurs to be further, overnight, that both approaches could even be
active at once, should the auto-everything turn out to be feasible down
the track.  If no stores have been presented - go with auto-everything,
else run in store-based mode... there's a nice clear path for progress
there, starting from something with the thin-layer-over-PAPI base, and
moving to your more experimental model.

> > The explicit-enabling method (pmstore) can map directly onto the
> > PAPI interfaces, so it comes with a 100% success guarantee - there
> > is no controversy over whether this approach will work, we all know
> > that it does and it has before.  [...]
> 
> It has tradition and a charming simplicity going for it, but it lacks

Tradition is largely irrelevant, I'm more into the simplicity and
code that works reliably.

> - 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?)

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).

> 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.


Anyway, I've outlined a stable, start-simple approach I'm happy with
merging/releasing, which I believe caters for all interested parties.
Lets start with that please, and slowly build to these lofty heights,
learning as we go & with the simpler thin-layer-over-PAPI base.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>