Message-ID: <7c86c4470901291344xbeb1b62scfa979cbd1549981@mail.gmail.com>
Date:	Thu, 29 Jan 2009 22:44:17 +0100
From:	stephane eranian <eranian@...glemail.com>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Dumazet <dada1@...mosbay.com>,
	Robert Richter <robert.richter@....com>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Mike Galbraith <efault@....de>,
	"perfmon2-devel@...ts.sourceforge.net" 
	<perfmon2-devel@...ts.sourceforge.net>,
	Papi <ptools-perfapi@...utk.edu>
Subject: Re: [announce] Performance Counters for Linux, v6

On Thu, Jan 29, 2009 at 9:01 PM, Corey Ashford
<cjashfor@...ux.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists