lkml.org 
[lkml]   [2009]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [announce] Performance Counters for Linux, v6
From
Corey,

On Thu, Jan 29, 2009 at 3:10 AM, Corey Ashford
<cjashfor@linux.vnet.ibm.com> wrote:
> Ingo Molnar wrote:
>>
>> We are pleased to announce version 6 of our performance counters subsystem
>> implementation. The shortlog, diffstat and the combo patch can be found
>> below. The combo patch against latest -git (2.6.29-rc2) can be also found
>> at:
>>
>>
>> http://people.redhat.com/mingo/perfcounters/perfcounters-v6-v2.6.29-rc2.patch
>>
>> It's also available in tip/master at:
>>
>> http://people.redhat.com/mingo/tip.git/README
>>
>> There are many changes in the v6 release:
>>
>> - PowerPC performance counters support from Paul Mackerras, for POWER6
>> and for the PPC970 family.
>>
>> - ioctl API to disable/enable individual counters and groups without
>> closing their fd. This can be useful for libraries, ad-hoc
>> instrumentation and PAPI support.
>>
>> - 'pinned' and 'exclusive' counter attributes - for those
>> applications that want to influence counter scheduling explicitly.
>>
>> - The 'perfstat' utility (ex 'timec') has been updated:
>>
>> http://people.redhat.com/mingo/perfcounters/perfstat.c
>>
>> - 'kerneltop' (easy-to-use text mode NMI profiler) has been updated:
>> http://people.redhat.com/mingo/perfcounters/kerneltop.c
>>
>> - Merged to latest mainline
>>
>> - Various fixes and other updates
>>
>> Ingo
>
> 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


\
 
 \ /
  Last update: 2009-01-29 13:35    [W:0.237 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site