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  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:	Mon, 01 Sep 2014 09:27:17 +0300
From:	Adrian Hunter <>
To:	Jiri Olsa <>
CC:	Arnaldo Carvalho de Melo <>,
	Peter Zijlstra <>,, David Ahern <>,
	Frederic Weisbecker <>,
	Namhyung Kim <>,
	Paul Mackerras <>,
	Stephane Eranian <>
Subject: Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without
 any config terms

On 08/30/2014 11:53 AM, Jiri Olsa wrote:
> On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote:
>> On 16/07/2014 9:22 p.m., Jiri Olsa wrote:
>>> On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote:
>>>> On 16/07/2014 5:25 p.m., Jiri Olsa wrote:
>>>>> On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote:
>>>>>> This enables a PMU event to be specified in the form:
>>>>>> 	pmu//
>>>>>> which is effectively the same as:
>>>>>> 	pmu/config=0/
>>>>>> This patch is a precursor to defining
>>>>>> default config for a PMU.
>>>>> I understand the need for default config, but could you please elaborate
>>>>> why do we want to parse 'pmu//' as an event string string?
>>>> Currently the parser requires the slashes to identify a PMU event
>>>> as opposed to a hardware or other kind of event.
>>> right, so why do we want to parse 'pmu//' as an event string? ;-)
>> I am not sure what you mean.  Here I am using 'pmu' as a placeholder
>> for a real PMU name.  So actual event strings are 'intel_bts//' or
>> 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/'
> so the consequence of default arguments is that you can
> specify event just by the pmu name, like:
>   -e intel_pt//
> which means (with default attributes):
>   -e intel_pt/tsc=1,noretcomp=0/
> I guess I wanted to hear more elaboration why is this better
> than the current way we have by defining an alias, like:
>   krava alias: "tsc=1,noretcomp=0"
>   -e intel_pt/krava/
> which gives the same result

The default value must be provided by perf tools not the kernel e.g.
an older version of perf tools will not be aware of new hardware
features that the kernel may know about.  If the kernel enables
new features by default then the tool may fail.  Thus the default
value has to be under the control of the tools not the kernel, so
a sysfs alias will not work.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists