From: Paul Mackerras <paulus@samba.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH/RFC 1/2] perfcounters: provide a way to read the current value of interrupting counters
Date: Tue, 17 Mar 2009 18:47:08 +1100 [thread overview]
Message-ID: <18879.21884.162961.690031@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <1237275169.5189.58.camel@laptop>
Peter Zijlstra writes:
> I'm not sure I understand why. It seems to me you're either interested
> in sample data, that is {tid,ip,counter} like things, or you want raw
> count values.
It was specifically requested by people porting PAPI to PCL, and it
seems like a reasonable request.
> This seems unrelated, what will stop us now from adding record_type
> values? PERF_RECORD_CALLCHAIN is one in particular I'd like to add soon.
I think we should make record_type a bitset rather than a single
value, and define bits for recording the callchain as well as various
other interesting things.
> This is a bit bothersome, as we then have no unique identifier anymore.
>
> Currently the group record type writes things like {hw_event->type,
> counter} which is ambiguous since we really have a 65bit id space. So I
> was thinking of making that {fd, counter} to at least have a unique
> identifier in there.
The fd is already not a unique identifier - think about dup().
The hw_event->type values are not really necessary, in fact, since the
group members will always be read out in the order that they were
added to the group. The only time there might be any possibility of
confusion is if a new member is added after some samples have already
been taken (or a member is removed) - then we'll get new records being
added to the event queue being a different size from those already in
the queue. But that's a somewhat different problem which isn't really
solved by having the type values in there.
Paul.
next prev parent reply other threads:[~2009-03-17 7:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 5:42 Paul Mackerras
2009-03-17 7:32 ` Peter Zijlstra
2009-03-17 7:47 ` Paul Mackerras [this message]
2009-03-17 8:37 ` Peter Zijlstra
2009-03-17 9:17 ` Paul Mackerras
2009-03-19 19:31 ` Corey Ashford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18879.21884.162961.690031@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®