pcp
[Top] [All Lists]

Re: Multi-Volume Archive + Live Data Playback for PCP Client Tools

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: Multi-Volume Archive + Live Data Playback for PCP Client Tools
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Mon, 3 Nov 2014 16:58:16 -0500
Cc: "'Dave Brolley'" <brolley@xxxxxxxxxx>, "'PCP Mailing List'" <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5457F82D.3050307@xxxxxxxxxxxxxxxx>
References: <542C21AE.1010504@xxxxxxxxxx> <007e01cfe010$7867f090$6937d1b0$@internode.on.net> <545110DC.2020104@xxxxxxxxxx> <y0mtx2hmwml.fsf@xxxxxxxx> <001d01cff6d7$0e9e4a50$2bdadef0$@internode.on.net> <20141103142643.GA3859@xxxxxxxxxx> <5457F82D.3050307@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi, Ken -

> >I don't know how pervasive this situation would be, but if it's not
> >too hard to support, we should.  (e.g., we could track metrics across
> >archives by name rather than pmid.)
> 
> This is not pervasive at all ... this is the only PMDA I am aware of 
> that behaves like this.

(Well, the cgroup.* PMNS hierarchy may be similarly affected, but that
is due for a revamp.)


> And I think I would be lobbying for the PMDA to be different, not
> the archive handling to be different. [...]  allow the papi pmda to
> maintain a consistent and persistent metric name to low-order bits
> of the PMID mapping. [...]

I see what you mena, but unfortunately, the PAPI event code space (at
least 32 bits) is much larger than the PMID low-order bits space, is
not densely encoded, and bound to get worse when we address counters
with extra option flags, "uncore" counters, and per-process/-cgroup.


- FChE

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