[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <499DD4BE.2000704@linux.vnet.ibm.com>
Date: Thu, 19 Feb 2009 13:53:02 -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:
>
[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@...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