linux-kernel - Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms

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]

Message-ID: <5405582C.6070402@intel.com>
Date:	Tue, 02 Sep 2014 08:39:56 +0300
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Jiri Olsa <jolsa@...hat.com>
CC:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Namhyung Kim <namhyung@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without
 any config terms

On 09/01/2014 10:11 PM, Jiri Olsa wrote:
> On Mon, Sep 01, 2014 at 09:27:17AM +0300, Adrian Hunter wrote:
>> 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.
>>
> 
> I dont follow, could u provide some example?

Imagine that the 'tsc' term did not exist.  Intel PT trace data
would not contain TSC packets, and the decoder would not know how to
decode them.  Then imagine that a new version of the hardware adds
'tsc'.  It is such a useful feature that we want it by default, but
older versions of the tools don't know how to decode it, so the
kernel cannot turn it on by default.

> 
> why the tool needs to understand.. it will just take the alias
> and apply/use it? The alias follows the format logic, which tells
> how to apply values on perf_event_attr.. and the kernel knows best
> what's supported in its version..

It is similar to why the kernel does not select mmap2 by default.  The
kernel doesn't know whether the tool supports it.

--
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/