perf/tracepoints access to interpreted strings

perf/tracepoints access to interpreted strings

[David Ahern]

Hi Steve:

I was hoping you could provide points on how to get access to an 
interpreted field in a tracepoint within perf.

This is an example of the tracepoint:

# cat /sys/kernel/debug/tracing/events/irq/softirq_exit/format
name: softirq_exit
ID: 99
format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;
	field:int common_padding;	offset:8;	size:4;	signed:1;

	field:unsigned int vec;	offset:12;	size:4;	signed:0;

print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec, { 
HI_SOFTIRQ, "HI" }, { TIMER_SOFTIRQ, "TIMER" }, { NET_TX_SOFTIRQ, 
"NET_TX" }, { NET_RX_SOFTIRQ, "NET_RX" }, { BLOCK_SOFTIRQ, "BLOCK" }, { 
BLOCK_IOPOLL_SOFTIRQ, "BLOCK_IOPOLL" }, { TASKLET_SOFTIRQ, "TASKLET" }, 
{ SCHED_SOFTIRQ, "SCHED" }, { HRTIMER_SOFTIRQ, "HRTIMER" }, { 
RCU_SOFTIRQ, "RCU" })


I would like to programmatically extract the action string. 'perf 
script' prints the samples fine which suggests libtraceevent extracts 
the information somehow.

Can you provide a suggestion -- something along the lines of 
perf_evsel__intval() or perf_evsel__rawptr()?

Thanks,
David

Re: perf/tracepoints access to interpreted strings

[Arnaldo Carvalho de Melo]

Em Wed, Apr 15, 2015 at 10:20:08AM -0600, David Ahern escreveu:
> I was hoping you could provide points on how to get access to an interpreted
> field in a tracepoint within perf.
 
> This is an example of the tracepoint:
 
> # cat /sys/kernel/debug/tracing/events/irq/softirq_exit/format
> name: softirq_exit
> ID: 99
> format:
> 	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
> 	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
> 	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
> 	field:int common_pid;	offset:4;	size:4;	signed:1;
> 	field:int common_padding;	offset:8;	size:4;	signed:1;
> 
> 	field:unsigned int vec;	offset:12;	size:4;	signed:0;
> 
> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec, {
> HI_SOFTIRQ, "HI" }, { TIMER_SOFTIRQ, "TIMER" }, { NET_TX_SOFTIRQ, "NET_TX"
> }, { NET_RX_SOFTIRQ, "NET_RX" }, { BLOCK_SOFTIRQ, "BLOCK" }, {
> BLOCK_IOPOLL_SOFTIRQ, "BLOCK_IOPOLL" }, { TASKLET_SOFTIRQ, "TASKLET" }, {
> SCHED_SOFTIRQ, "SCHED" }, { HRTIMER_SOFTIRQ, "HRTIMER" }, { RCU_SOFTIRQ,
> "RCU" })
 
> I would like to programmatically extract the action string. 'perf script'
> prints the samples fine which suggests libtraceevent extracts the
> information somehow.
 
> Can you provide a suggestion -- something along the lines of
> perf_evsel__intval() or perf_evsel__rawptr()?

We'll gonna have to parse the "print fmt" thing and look for entries
surrounded by [], then match it with the list of parameters, so that we
can end up with a:

	const char *perf_evsel__enum_entry(struct perf_evsel *evsel,
					   struct perf_sample *sample,
					   const char *enum_name,
					   int value);

That would return one of "TIMER", "NET_TX", etc, that is, 0,
1, N.

If it is strictly an enum, i.e. no holes and just by looking at the
"format" file above I don't see how it could have holes, albeit enums
may have, we can as well have this:

	const char *perf_evsel__enum(struct perf_evsel *evsel,
				     struct perf_sample *sample,
				     const char *enum_name);

That would return an array of strings that you could directly access,
indexing using some of the fields.

I.e. internally we would see the tracepoint format file as:

 	field:enum action vec;	offset:12;	size:4;	signed:0;

	enum: action: TIMER, NET_TX, NET_RX, BLOCK, BLOCK_IOPOLL, TASKLET, SCHED, HRTIMER, RCU

- Arnaldo

Re: perf/tracepoints access to interpreted strings

[Steven Rostedt]

On Wed, 15 Apr 2015 15:09:27 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Wed, Apr 15, 2015 at 10:20:08AM -0600, David Ahern escreveu:
> > I was hoping you could provide points on how to get access to an interpreted
> > field in a tracepoint within perf.
>  
> > This is an example of the tracepoint:
>  
> > # cat /sys/kernel/debug/tracing/events/irq/softirq_exit/format
> > name: softirq_exit
> > ID: 99
> > format:
> > 	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
> > 	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
> > 	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
> > 	field:int common_pid;	offset:4;	size:4;	signed:1;
> > 	field:int common_padding;	offset:8;	size:4;	signed:1;
> > 
> > 	field:unsigned int vec;	offset:12;	size:4;	signed:0;
> > 
> > print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec, {
> > HI_SOFTIRQ, "HI" }, { TIMER_SOFTIRQ, "TIMER" }, { NET_TX_SOFTIRQ, "NET_TX"
> > }, { NET_RX_SOFTIRQ, "NET_RX" }, { BLOCK_SOFTIRQ, "BLOCK" }, {
> > BLOCK_IOPOLL_SOFTIRQ, "BLOCK_IOPOLL" }, { TASKLET_SOFTIRQ, "TASKLET" }, {
> > SCHED_SOFTIRQ, "SCHED" }, { HRTIMER_SOFTIRQ, "HRTIMER" }, { RCU_SOFTIRQ,
> > "RCU" })
>  
> > I would like to programmatically extract the action string. 'perf script'
> > prints the samples fine which suggests libtraceevent extracts the
> > information somehow.
>  
> > Can you provide a suggestion -- something along the lines of
> > perf_evsel__intval() or perf_evsel__rawptr()?
> 
> We'll gonna have to parse the "print fmt" thing and look for entries
> surrounded by [], then match it with the list of parameters, so that we
> can end up with a:
> 
> 	const char *perf_evsel__enum_entry(struct perf_evsel *evsel,
> 					   struct perf_sample *sample,
> 					   const char *enum_name,
> 					   int value);
> 
> That would return one of "TIMER", "NET_TX", etc, that is, 0,
> 1, N.
> 
> If it is strictly an enum, i.e. no holes and just by looking at the
> "format" file above I don't see how it could have holes, albeit enums
> may have, we can as well have this:
> 
> 	const char *perf_evsel__enum(struct perf_evsel *evsel,
> 				     struct perf_sample *sample,
> 				     const char *enum_name);
> 
> That would return an array of strings that you could directly access,
> indexing using some of the fields.
> 
> I.e. internally we would see the tracepoint format file as:
> 
>  	field:enum action vec;	offset:12;	size:4;	signed:0;
> 
> 	enum: action: TIMER, NET_TX, NET_RX, BLOCK, BLOCK_IOPOLL, TASKLET, SCHED, HRTIMER, RCU
> 

Note, with the new TRACE_DEFINE_ENUM() that was already added to
Linus's tree, that print_fmt now looks like:

print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
 { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
 { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
 { 9, "RCU" })


-- Steve

Re: perf/tracepoints access to interpreted strings

[Arnaldo Carvalho de Melo]

Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
> On Wed, 15 Apr 2015 15:09:27 -0300
> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > If it is strictly an enum, i.e. no holes and just by looking at the
> > "format" file above I don't see how it could have holes, albeit enums
> > may have, we can as well have this:

> > 	const char *perf_evsel__enum(struct perf_evsel *evsel,
> > 				     struct perf_sample *sample,
> > 				     const char *enum_name);

> > That would return an array of strings that you could directly access,
> > indexing using some of the fields.

> > I.e. internally we would see the tracepoint format file as:

> >  	field:enum action vec;	offset:12;	size:4;	signed:0;

> > 	enum: action: TIMER, NET_TX, NET_RX, BLOCK, BLOCK_IOPOLL, TASKLET, SCHED, HRTIMER, RCU

> Note, with the new TRACE_DEFINE_ENUM() that was already added to
> Linus's tree, that print_fmt now looks like:
 
> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
>  { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
>  { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
>  { 9, "RCU" })

That is better, indeed, covers holes :-)

- Arnaldo

Re: perf/tracepoints access to interpreted strings

[David Ahern]

On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
>> On Wed, 15 Apr 2015 15:09:27 -0300
>> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>>> If it is strictly an enum, i.e. no holes and just by looking at the
>>> "format" file above I don't see how it could have holes, albeit enums
>>> may have, we can as well have this:
>
>>> 	const char *perf_evsel__enum(struct perf_evsel *evsel,
>>> 				     struct perf_sample *sample,
>>> 				     const char *enum_name);
>
>>> That would return an array of strings that you could directly access,
>>> indexing using some of the fields.
>
>>> I.e. internally we would see the tracepoint format file as:
>
>>>   	field:enum action vec;	offset:12;	size:4;	signed:0;
>
>>> 	enum: action: TIMER, NET_TX, NET_RX, BLOCK, BLOCK_IOPOLL, TASKLET, SCHED, HRTIMER, RCU
>
>> Note, with the new TRACE_DEFINE_ENUM() that was already added to
>> Linus's tree, that print_fmt now looks like:
>
>> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
>>   { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
>>   { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
>>   { 9, "RCU" })
>
> That is better, indeed, covers holes :-)

Seems to me that means 2 different implementations are needed ... old 
and new.

Re: perf/tracepoints access to interpreted strings

[Namhyung Kim]

Hi David,

On Mon, Apr 20, 2015 at 03:26:56PM -0600, David Ahern wrote:
> On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
> >Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
> >>On Wed, 15 Apr 2015 15:09:27 -0300
> >>Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >>>If it is strictly an enum, i.e. no holes and just by looking at the
> >>>"format" file above I don't see how it could have holes, albeit enums
> >>>may have, we can as well have this:
> >
> >>>	const char *perf_evsel__enum(struct perf_evsel *evsel,
> >>>				     struct perf_sample *sample,
> >>>				     const char *enum_name);
> >
> >>>That would return an array of strings that you could directly access,
> >>>indexing using some of the fields.
> >
> >>>I.e. internally we would see the tracepoint format file as:
> >
> >>>  	field:enum action vec;	offset:12;	size:4;	signed:0;
> >
> >>>	enum: action: TIMER, NET_TX, NET_RX, BLOCK, BLOCK_IOPOLL, TASKLET, SCHED, HRTIMER, RCU
> >
> >>Note, with the new TRACE_DEFINE_ENUM() that was already added to
> >>Linus's tree, that print_fmt now looks like:
> >
> >>print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
> >>  { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
> >>  { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
> >>  { 9, "RCU" })
> >
> >That is better, indeed, covers holes :-)
> 
> Seems to me that means 2 different implementations are needed ... old and
> new.

I just called pevent_event_info() and parsed the output seq.buffer for
my perf kmem work to parse GFP flags.

Thanks,
Namhyung

Re: perf/tracepoints access to interpreted strings

[Steven Rostedt]

On Mon, 20 Apr 2015 15:26:56 -0600
David Ahern <dsahern@gmail.com> wrote:

> On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
> >> On Wed, 15 Apr 2015 15:09:27 -0300
> >> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >>> If it is strictly an enum, i.e. no holes and just by looking at the
> >>> "format" file above I don't see how it could have holes, albeit enums
> >>> may have, we can as well have this:
> >
> >>> 	const char *perf_evsel__enum(struct perf_evsel *evsel,
> >>> 				     struct perf_sample *sample,
> >>> 				     const char *enum_name);
> >
> >>> That would return an array of strings that you could directly access,
> >>> indexing using some of the fields.
> >
> >>> I.e. internally we would see the tracepoint format file as:
> >
> >>>   	field:enum action vec;	offset:12;	size:4;	signed:0;
> >
> >>> 	enum: action: TIMER, NET_TX, NET_RX, BLOCK, BLOCK_IOPOLL, TASKLET, SCHED, HRTIMER, RCU
> >
> >> Note, with the new TRACE_DEFINE_ENUM() that was already added to
> >> Linus's tree, that print_fmt now looks like:
> >
> >> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
> >>   { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
> >>   { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
> >>   { 9, "RCU" })
> >
> > That is better, indeed, covers holes :-)
> 
> Seems to me that means 2 different implementations are needed ... old 
> and new.

Why? The above is the way most trace points use __print_symbolic().
It's just when a tracepoint uses enums instead of defines or hard coded
numbers do the useless enum name pops up.

Any parse should be expecting numbers, not enum names.

-- Steve

Re: perf/tracepoints access to interpreted strings

[Arnaldo Carvalho de Melo]

Em Tue, Apr 21, 2015 at 09:07:33AM -0400, Steven Rostedt escreveu:
> On Mon, 20 Apr 2015 15:26:56 -0600 David Ahern <dsahern@gmail.com> wrote:
> > On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
> > >> On Wed, 15 Apr 2015 15:09:27 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > >> Note, with the new TRACE_DEFINE_ENUM() that was already added to
> > >> Linus's tree, that print_fmt now looks like:

> > >> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
> > >>   { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
> > >>   { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
> > >>   { 9, "RCU" })

> > > That is better, indeed, covers holes :-)

> > Seems to me that means 2 different implementations are needed ... old 
> > and new.
 
> Why? The above is the way most trace points use __print_symbolic().

I think he is talking about any user space implementation handling those
enum->STR mappings, __print_symbolic() included.

> It's just when a tracepoint uses enums instead of defines or hard coded
> numbers do the useless enum name pops up.
 
> Any parse should be expecting numbers, not enum names.

Humm, I found that the point was that on field 'vec' we receive a
number, and we want to format it to something less cryptic, so we need
to map a number to a string.

The original implementation, that doesn't have that { number, string }
will fail to handle sparse enums, because we can't map number -> "string".

So it has to handle both:

1)    { string, "string" } 
2)    { number, "string" }

And for 1) keep some blacklist of { tracepoint, field-list } that can't
be safely mapped number -> "string", i.e. a blacklist of sparse enums,
no?

David, we could as well just blacklist all kernels where 1) is used and
do no mapping, supporting only 2) kernels. We can do that by parsing
the first element, and if it is not a number, blacklist it.

- Arnaldo