This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [pcp] suitability of PCP for event tracing
- From: Nathan Scott <nathans at aconex dot com>
- To: Max Matveev <makc at gmx dot co dot uk>
- Cc: pcp at oss dot sgi dot com, "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com, Ken McDonell <kenj at internode dot on dot net>
- Date: Sun, 19 Sep 2010 19:48:56 +1000 (EST)
- Subject: Re: [pcp] suitability of PCP for event tracing
----- "Max Matveev" <makc@gmx.co.uk> wrote:
> On Sun, 19 Sep 2010 00:21:34 +1000, Ken McDonell wrote:
>
> kenj> On 17/09/2010 9:18 AM, nathans@aconex.com wrote:
>
> kenj> For the existing tools, I think we'll probably end up adding a
> kenj> routine to libpcp to turn a PM_TYPE_EVENT "blob" into a
> kenj> pmResult ... this will work for pminfo and pmprobe where the
> kenj> timestamps are ignored. For pmie, pmval, pmdumptext, pmchart,
> kenj> ... I'm not sure how they can make sense of the event trace
> kenj> data in real time, expecting data from time t, and getting a
> kenj> set of values with different timestamps smaller than t is
> going
> kenj> to be a bit odd for these ones.
>
> I've been trying to come up with the use-case where event data and
> statistical data could be useful in the live mode (current tools
> issue
> aside) and I cannot really see one - Nathan or Frank, what did you
> have in mind?
One example was mentioned earlier - http://www.bootchart.org/
I'd want to extend it well beyond that use case though.
> kenj> Plus several variants around lists per client or bit maps per
> client to
> kenj> reduce matching overhead on each pmFetch.
>
> How would per-client list entries be trimmed?
Yeah, thats pretty much what I was wondering. Have to at least ensure
memory use is bounded and small, and really can't have memory utilisation
dependent on number of clients, IMO.
cheers.
--
Nathan