From: stephane eranian <eranian@googlemail.com>
To: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Eric Dumazet <dada1@cosmosbay.com>,
Robert Richter <robert.richter@amd.com>,
Arjan van de Ven <arjan@infradead.org>,
Peter Anvin <hpa@zytor.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
Mike Galbraith <efault@gmx.de>,
"perfmon2-devel@lists.sourceforge.net"
<perfmon2-devel@lists.sourceforge.net>,
Papi <ptools-perfapi@cs.utk.edu>
Subject: Re: [announce] Performance Counters for Linux, v6
Date: Thu, 29 Jan 2009 22:44:17 +0100 [thread overview]
Message-ID: <7c86c4470901291344xbeb1b62scfa979cbd1549981@mail.gmail.com> (raw)
In-Reply-To: <49820B03.6010807@linux.vnet.ibm.com>
On Thu, Jan 29, 2009 at 9:01 PM, Corey Ashford
<cjashfor@linux.vnet.ibm.com> wrote:
>>>
>>> I'm not sure if this is the right place to propose such a thing, but I
>>> think
>>> it would be very valuable to have a standardized user-side library to
>>> accompany this addition to the kernel.
>>>
>>> In particular, as a starting place for the discussion, I'd like to see
>>> functions in it that are very similar to a subset of what is currently in
>>> libpfm. Specifically, I'd like to see the following functions (with the
>>> names changed to pcl_* perhaps):
>>>
>>> extern pfm_err_t pfm_find_event(const char *str, unsigned int *idx);
>>> extern pfm_err_t pfm_find_event_bycode(int code, unsigned int *idx);
>>> extern pfm_err_t pfm_find_event_bycode_next(int code, unsigned int start,
>>> unsigned int *next);
>>> extern pfm_err_t pfm_find_event_mask(unsigned int event_idx, const char
>>> *str,
>>> unsigned int *mask_idx);
>>> extern pfm_err_t pfm_find_full_event(const char *str, pfmlib_event_t *e);
>>>
>>> extern pfm_err_t pfm_get_max_event_name_len(size_t *len);
>>>
>>> extern pfm_err_t pfm_get_num_events(unsigned int *count);
>>> extern pfm_err_t pfm_get_num_event_masks(unsigned int event_idx,
>>> unsigned int *count);
>>> extern pfm_err_t pfm_get_event_name(unsigned int idx, char *name,
>>> size_t maxlen);
>>> extern pfm_err_t pfm_get_full_event_name(pfmlib_event_t *e, char *name,
>>> size_t maxlen);
>>> extern pfm_err_t pfm_get_event_code(unsigned int idx, int *code);
>>> extern pfm_err_t pfm_get_event_mask_code(unsigned int idx,
>>> unsigned int mask_idx,
>>> unsigned int *code);
>>> extern pfm_err_t pfm_get_event_description(unsigned int idx, char **str);
>>> extern pfm_err_t pfm_get_event_code_counter(unsigned int idx, unsigned
>>> int
>>> cnt,
>>> int *code);
>>> extern pfm_err_t pfm_get_event_mask_name(unsigned int event_idx,
>>> unsigned int mask_idx,
>>> char *name, size_t maxlen);
>>> extern pfm_err_t pfm_get_event_mask_description(unsigned int event_idx,
>>> unsigned int mask_idx,
>>> char **desc);
>>>
>>>
>>> Now, since it's not clear right now how unit masks are going to be
>>> handled
>>> in your proposal, I'm not sure the that *_event_mask_* functions are
>>> applicable, but I think something that fills that function will be
>>> needed.
>>>
>>> Architectures that have need for additional functionality should be free
>>> to
>>> add arch-specific functions.
>>>
>>> Full descriptions of these functions can be found in the man pages of the
>>> libpfm documentation.
>>>
>>> Any thoughts on this? Do you already have a us
>>
>> er library structure in mind?
>> Yes, I did give some thoughts to all of this. In fact, I have been
>> playing a bit with
>> libpfm and the LPC proposal.
>>
>> I think, given that LPC is dealing with event -> counter assignment in
>> the kernel, libpfm
>> does not have to do it. All it needs to do is event:attributes ->
>> value, and that value is
>> then passed to the kernel in raw mode.
>>
>> Event attributes includes on x86, for instance, the edge, invert,
>> counter-mask, plm, field.
>> I think we could do something more generic than what is currently
>> there. That would not
>> require PMU specific data structures for attributes. Just pass
>> everything into a string.
>>
>> To that extent, I have been experimenting with something along those
>> lines:
>>
>> int pfm_get_event_encoding(char *event_str, uint64_t **values, int
>> *count);
>>
>> events are encoded as follows:
>>
>>
>> event_name:[unit_mask1:unit_mask2:...:unit_maskn][::A1=V1:A2=V2:..:An=Vn]
>>
>> Attribute names and values depend on each PMU model. Attributes names
>> are strings.
>> Values can have any type.
>>
>> For X86, most attributes would be identical, same thing on Itanium
>> because they are
>> architected.
>>
>> Some PMU models may need more than one 64-bit value to configure one
>> event, That is
>> is why there is vector and a count. Libpfm should not be concerned
>> with how those values
>> are encoded and passed to the kernel. It should be concerned with the
>> event -> value
>> as described in the PMU documentation.
>>
>> Given that LPC manages events independently of each other, libpfm does
>> not reallly need
>> to process multiple events at a time to get a global view of what is
>> being measured.
>>
>> Here is an example:
>>
>> $ self inst_retired:any_p::i=1:c=1:u=1:k=1
>> [0x1d300c0 event_sel=0xc0 umask=0x0 os=1 usr=1 en=1 int=1 inv=1 edge=0
>> cnt_mask=1] INST_RETIRED
>
> This looks encouraging!
>
> I assume the library would still retain the functions that allow us to
> iterate through the available events, and obtain text description of events.
> Would it make sense to have similar functions to obtain the available unit
> masks and attributes for a particular event?
>
Yes, that would most likely stay there, although, I think we could
simplify a bit.
> For debugging purposes at least, it might make sense to have a function that
> does the inverse of pfm_get_event_encoding as well.
>
Yes, we could provide the opposite function.
I also believe this same scheme could be used to describe non-event features,
such as IBS, LBR, Opcode matcher.
next prev parent reply other threads:[~2009-01-29 21:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 18:50 Ingo Molnar
2009-01-21 19:34 ` Randy Dunlap
2009-01-21 19:56 ` Ingo Molnar
2009-01-21 21:14 ` Randy Dunlap
2009-01-22 11:22 ` Karel Zak
2009-01-22 12:04 ` Karel Zak
2009-01-22 12:06 ` Ingo Molnar
2009-01-26 1:06 ` Corey Ashford
2009-01-26 9:13 ` stephane eranian
2009-01-26 15:17 ` Ingo Molnar
2009-01-26 16:55 ` stephane eranian
2009-01-26 19:13 ` Corey Ashford
2009-01-26 19:39 ` [perfmon2] " Luck, Tony
2009-01-26 22:10 ` Ingo Molnar
2009-01-26 22:15 ` Ingo Molnar
2009-01-26 23:41 ` Corey Ashford
2009-01-29 2:10 ` Corey Ashford
2009-01-29 12:32 ` stephane eranian
2009-01-29 20:01 ` Corey Ashford
2009-01-29 21:44 ` stephane eranian [this message]
2009-02-19 21:53 ` Corey Ashford
2009-02-20 8:10 ` Ingo Molnar
2009-02-20 22:38 ` Corey Ashford
2009-02-20 22:47 ` Peter Zijlstra
2009-02-20 23:04 ` Corey Ashford
2009-02-20 23:24 ` stephane eranian
2009-02-20 23:58 ` Corey Ashford
2009-02-21 0:47 ` Arnd Bergmann
2009-02-26 9:49 ` Paul Mackerras
2009-02-26 13:37 ` Arnd Bergmann
2009-03-09 1:39 ` Robert Richter
2009-03-09 23:01 ` Paul Mackerras
2009-03-10 9:44 ` Robert Richter
2009-03-10 10:29 ` Peter Zijlstra
2009-03-10 11:49 ` Paul Mackerras
2009-03-10 11:53 ` Ingo Molnar
2009-03-10 16:26 ` Robert Richter
2009-03-10 17:27 ` Ingo Molnar
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=7c86c4470901291344xbeb1b62scfa979cbd1549981@mail.gmail.com \
--to=eranian@googlemail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=efault@gmx.de \
--cc=eranian@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sourceforge.net \
--cc=ptools-perfapi@cs.utk.edu \
--cc=robert.richter@amd.com \
--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®