[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <58C94657.1010307@linux.vnet.ibm.com>
Date: Wed, 15 Mar 2017 19:19:11 +0530
From: Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>
Cc: mingo@...hat.com, mhiramat@...nel.org, brendan.d.gregg@...il.com,
peterz@...radead.org, alexander.shishkin@...ux.intel.com,
wangnan0@...wei.com, jolsa@...nel.org, ak@...ux.intel.com,
treeze.taeung@...il.com, mathieu.poirier@...aro.org,
hekuang@...wei.com, sukadev@...ux.vnet.ibm.com, ananth@...ibm.com,
naveen.n.rao@...ux.vnet.ibm.com, adrian.hunter@...el.com,
linux-kernel@...r.kernel.org, hemant@...ux.vnet.ibm.com,
Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
Subject: Re: [PATCH v5 3/7] perf/sdt: Directly record SDT events with 'perf
record'
On Wednesday 15 March 2017 06:46 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 15, 2017 at 01:03:31PM +0100, Jiri Olsa escreveu:
>> On Tue, Mar 14, 2017 at 08:36:54PM +0530, Ravi Bangoria wrote:
>>> +++ b/tools/perf/builtin-record.c
>>> +static int record__parse_events_option(const struct option *opt,
>>> + const char *str,
>>> + int unset)
>>> +{
>>> + if (is_sdt_event((char *) str))
>>> + return parse_sdt_events_option(opt, str, unset);
>>> + else
>>> + return parse_events_option(opt, str, unset);
>> so what happens if there're more than one event in 'str' like:
>> -e cycles,std_...
>>
>> would it be better to plug this directly into parse-events.y
>> parser.. and handle it like any other event type?
> Yeah, I went to bed thinking about this :-)
>
> Ravi,
>
> Please test something like:
>
> perf record -e cycles,sdt_glib:mem__alloc,sched:*switch -a sleep 5s
Thanks Jiri, Arnaldo,
Yeah, this is failing :)
$ sudo ./perf record -a -e sdt_libpthread:mutex_release,sced:*switch
Error: sdt_libpthread:mutex_release,sched:*switch not found in the cache
invalid or unsupported event: 'sdt_libpthread:mutex_release,sched:*switch'
Actually I tested with 'perf record -e ev1 -e ev2', but in this case
record__parse_events_option will get called separately for each
individual event.
Anyway, I'll fix this in next version.
Thanks for the review,
Ravi
Powered by blists - more mailing lists