public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Ashford <cjashfor@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephane Eranian <eranian@googlemail.com>,
	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>
Subject: Re: [announce] Performance Counters for Linux, v6
Date: Thu, 19 Feb 2009 13:53:02 -0800	[thread overview]
Message-ID: <499DD4BE.2000704@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090121185021.GA8852@elte.hu>

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:
> 
[snip]

Hi Ingo,

As I was starting to put together a simple implementation of PAPI on top 
of PCL for Power, I noticed that PCL does not seem to have any sort of 
versioning and way of ascertaining the current capabilities of what is 
in the kernel.

This information is needed by tools and libraries built on top of PCL so 
that they can know what is supported and if any bugs need to be worked 
around.

Have you thought about how to present this information to the user?  I 
was thinking that since you already have 
/sys/devices/system/cpu/perf_counter set up, maybe we could add some 
more files in there.  Perhaps a "version" file (perfmon does this), and 
maybe a "capabilities" file which contains a set of strings exhibiting 
the supported features.  For example,

arch-independent:
MMAPPED_SAMPLE_BUFFER
MMAPPED_SAMPLE_BUFFER_MAX_SIZE=0x20000
CUSTOM_SAMPLING

on powerpc arch:
POWER6_IMC
POWER6_THRESHOLD

or on x86:
NEHALEM_PEBS

etc.

Or it could be a bit mask whose bits are defined in an include file.

Personally, I like the strings approach because it's more extensible, 
and would not require modifying /usr/include files when you pick up a 
new kernel.  Perhaps the arch-independent and arch-dependent 
capabilities would be in two different files to make the implementation 
easier.


-- 
Regards,

- Corey

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


  parent reply	other threads:[~2009-02-19 21:53 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-21 18:50 [announce] Performance Counters for Linux, v6 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
2009-02-19 21:53 ` Corey Ashford [this message]
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=499DD4BE.2000704@linux.vnet.ibm.com \
    --to=cjashfor@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=efault@gmx.de \
    --cc=eranian@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --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