Thread (16 messages) flat view 16 messages, 4 authors, 2014-10-01

Re: [PATCH v4 01/10] tools/perf: support parsing parameterized events

From: Peter Zijlstra <peterz@infradead.org>
Date: 2014-10-01 16:00:08
Also in: lkml

On Wed, Oct 01, 2014 at 11:06:27AM +0200, Jiri Olsa wrote:
On Thu, Sep 25, 2014 at 07:25:20PM -0700, Sukadev Bhattiprolu wrote:
quoted
Jiri Olsa [jolsa@redhat.com] wrote:
| On Wed, Sep 24, 2014 at 12:27:15PM -0700, Sukadev Bhattiprolu wrote:
| > From: Cody P Schafer [off-list ref]
| > 
| > Enable event specification like:
| > 
| > 	pmu/event_name,param1=0x1,param2=0x4/
| > 
| > Assuming that
| > 
| > 	/sys/bus/event_source/devices/pmu/events/event_name
| > 
| > Contains something like
| > 
| > 	param2=foo,bar=1,param1=baz
| 
| hum, so what happened to the '?' ... AFAIU from out last discussion,
| you wanted to mark terms which are mandatory and user must provide
| values for them.. and I thought the decision was to have following
| alias record:
| 
|   $ cat /sys/bus/event_source/devices/pmu/events/event_name
|   param2=?,bar=1,param1=?
| 
| while perf would scream if any of param1/2 wasnt filled like for:
|   pmu/event_name,param1=0x1/

Sorry, I meant to make perf list consistent with sysfs.

Consider these two sysfs entries:

	$ cat HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE 
	domain=0x2,offset=0xe0,starting_index=core,lpar=0x0

	$ cat HPM_0THRD_NON_IDLE_CCYC__VCPU_HOME_CORE 
	domain=0x3,offset=0xe0,starting_index=vcpu,lpar=sibling_guest_id

In the first one, starting_index refers to a 'core' while in the second
it refers to a vcpu. This serves as a "hint" for the parameter's meaning.

By replacing both with 'starting_index=?' we lose that hint.

Should we fix both sysfs and 'perf list' to say

	starting_index=?core 
Peter, Ingo,
any opinions on this? Overall explanation is in here:
http://marc.info/?l=linux-kernel&m=141158688307356&w=2
Consistency is good, and you indeed need to indicate it is a parameter.
I'm not entirely sure about ?core, but I suppose its easy to parse and
clear enough to read.

So the typical optional argument syntax would be like $arg or <type>
like. But overall I have no objection as long as you keep the lot
consistent and parsable.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help