Re: [announce] Performance Counters for Linux, v6

[Corey Ashford <cjashfor@linux.vnet.ibm.com>]

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 user library structure in mind?

-- 
Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@us.ibm.com