[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4981102C.2000400@linux.vnet.ibm.com>
Date: Wed, 28 Jan 2009 18:10:52 -0800
From: Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To: Ingo Molnar <mingo@...e.hu>
CC: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Stephane Eranian <eranian@...glemail.com>,
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>
Subject: Re: [announce] Performance Counters for Linux, v6
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@...ibm.com
--
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