[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBT5iQo00Wi3dX6uZQqrGWm-H-Q6GMFHUmupnodVUWngXg@mail.gmail.com>
Date: Thu, 5 Apr 2012 10:06:23 -0700
From: Stephane Eranian <eranian@...gle.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: acme@...hat.com, a.p.zijlstra@...llo.nl, mingo@...e.hu,
paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>
Subject: Re: [PATCH 5/8] perf, tool: Add pmu event parse support for
branch_sample_type values
On Thu, Apr 5, 2012 at 1:59 AM, Jiri Olsa <jolsa@...hat.com> wrote:
> On Wed, Apr 04, 2012 at 09:50:12PM -0700, Stephane Eranian wrote:
>> On Wed, Apr 4, 2012 at 1:21 PM, Jiri Olsa <jolsa@...hat.com> wrote:
>> > Adding a support to specify branch_type as a hardcoded term
>> > inside the pmu event definition.
>> >
>> > It is possible to specify pmu event like:
>> > "cpu/config=1,branch_type=hv|any_ret|1,config2=2/u"
>> >
>> > Following string values could be used as value for branch_type:
>> > u (PERF_SAMPLE_BRANCH_USER)
>> > k (PERF_SAMPLE_BRANCH_KERNEL)
>> > hv (PERF_SAMPLE_BRANCH_HV)
>> > any (PERF_SAMPLE_BRANCH_ANY)
>> > any_call (PERF_SAMPLE_BRANCH_ANY_CALL)
>> > any_ret (PERF_SAMPLE_BRANCH_ANY_RETURN)
>> > ind_call (PERF_SAMPLE_BRANCH_IND_CALL)
>> >
>> > Also a number could be specified as value.
>> >
>> Although it would be nice to have, the current kernel sampling
>> buffer layout + perf would not be able to parse the RECORD_SAMPLE
>> if you were to sample different things for different events:
>>
>> perf record -e
>> cpu/event=0xc0,umask=1:branch_type=any/,cpu/event=0x3c,umask=0x1/
> hi,
> for some reason I thought there might be sense to have multiple branch
> types enabled in a single event.. I misread the code probably
>
You can combine the branch types but I don't see how
this could be really useful. As for priv levels, you can of course
combine them. If they are not specificied, then the levels of
the associated event are used.
>>
>> Perf report/annotate would not be able to distinguish a RECORD_SAMPLE
>> generated by the first or the second event. That's because the RECORD_SAMPLE
>> fixed header does not contain enough info to determine which event caused the
>> record to be generated. You need to event ID to decode the sample. The event ID
>> gives you the attr struct which gives you the attr->sample_type which drives the
>> layout of the RECORD_SAMPLE variable size body. The event ID is currently
>> saved "somewhere" in the variable-size body of the sample. You have a chicken
>> and egg problem here.
>
> yep, I'm aware of this.. cool you're preparing fix
>
> thanks,
> jirka
--
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