lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ