Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1465024 > unrolled thread

[PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Masami Hiramatsu <mhiramat@kernel.org> - 2016-08-18 11:10 +0200
    Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-08-18 16:40 +0200
      Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Masami Hiramatsu <mhiramat@kernel.org> - 2016-08-18 18:30 +0200
        Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-08-19 03:50 +0200
          Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Masami Hiramatsu <mhiramat@kernel.org> - 2016-08-20 05:50 +0200
    Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-08-18 18:30 +0200
    Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Steven Rostedt <rostedt@goodmis.org> - 2016-08-19 04:00 +0200

#1465024 — [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting

Hi Arnaldo and Steven,

Here is an RFC series of hexadecimal type casting and
changing default type casting of perf and ftrace.

I've introduced x8,x16,x32,x64 according to previous
discussion on LKML.
  https://lkml.org/lkml/2016/8/10/339

This series includes not only adding hexadecimal types
(x8,x16,x32,x64), but also checking it is supported by
running kernel and keeping the backward compativility.

[1/6] Add hexadecimal type casting, but does not touch
   existing types like 'u8'.
[2/6] Show the supported types on README of ftrace so
   that user application (e.g. perf) can check that.
[3/6] Add a type availability check to perf-probe.
[4/6] Add hexadecimal prefix support to perf-probe if
   it is supported by the kernel. 
[5/6] Change the perf-probe default type casting for
   unsigned type to hexadecimal (for backward compatibility)
[6/6] Change ftrace's 'uNN' to show value in decimal
   and use 'xNN' by default (for backward compatibility)

This way, we can also add "octal" type, pointer type,
and "character" type etc. and perf can check whether
the kernel supports it or not. :)

Thanks,
---

Masami Hiramatsu (6):
      ftrace: kprobe: uprobe: Add x8/x16/x32/x64 for hexadecimal types
      ftrace: probe: Add README entries for k/uprobe-events
      perf probe: Add supported type casting of running kernel
      perf probe: Support hexadecimal casting
      perf-probe: Use hexadecimal type by default if possible
      ftrace: kprobe: uprobe: Show u8/u16/u32/u64 types in decimal


 tools/perf/Documentation/perf-probe.txt |    5 +--
 tools/perf/util/probe-file.c            |   57 +++++++++++++++++++++++++++++++
 tools/perf/util/probe-file.h            |   10 +++++
 tools/perf/util/probe-finder.c          |   19 +++++++---
 4 files changed, 81 insertions(+), 10 deletions(-)

--
Masami Hiramatsu (Linaro Ltd.) <mhiramat@kernel.org>

[toc] | [next] | [standalone]

#1465547

Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:
> Hi Arnaldo and Steven,
> 
> Here is an RFC series of hexadecimal type casting and
> changing default type casting of perf and ftrace.
> 
> I've introduced x8,x16,x32,x64 according to previous
> discussion on LKML.
>   https://lkml.org/lkml/2016/8/10/339
> 
> This series includes not only adding hexadecimal types
> (x8,x16,x32,x64), but also checking it is supported by
> running kernel and keeping the backward compativility.
> 
> [1/6] Add hexadecimal type casting, but does not touch
>    existing types like 'u8'.
> [2/6] Show the supported types on README of ftrace so
>    that user application (e.g. perf) can check that.
> [3/6] Add a type availability check to perf-probe.
> [4/6] Add hexadecimal prefix support to perf-probe if
>    it is supported by the kernel. 
> [5/6] Change the perf-probe default type casting for
>    unsigned type to hexadecimal (for backward compatibility)
> [6/6] Change ftrace's 'uNN' to show value in decimal
>    and use 'xNN' by default (for backward compatibility)
> 
> This way, we can also add "octal" type, pointer type,
> and "character" type etc. and perf can check whether
> the kernel supports it or not. :)

But this requires a kernel update... If we do it all in the tooling
side, no kernel changes are required _and_ newer tools will work with
older kernels, as this is just a formatting issue, the value is there
and from its format one can infer its value, it is not even necessary to
look at its "type".

I understand this is necessary for ftrace, because the pretty printer is
in the kernel, but I don't see why we would prevent tooling from doing
this pretty printing work and make it support any kernel.

I.e. no need at all for checking if the kernel supports anything, just
pretty print it.

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1465650

On Thu, 18 Aug 2016 11:14:42 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:
> > Hi Arnaldo and Steven,
> > 
> > Here is an RFC series of hexadecimal type casting and
> > changing default type casting of perf and ftrace.
> > 
> > I've introduced x8,x16,x32,x64 according to previous
> > discussion on LKML.
> >   https://lkml.org/lkml/2016/8/10/339
> > 
> > This series includes not only adding hexadecimal types
> > (x8,x16,x32,x64), but also checking it is supported by
> > running kernel and keeping the backward compativility.
> > 
> > [1/6] Add hexadecimal type casting, but does not touch
> >    existing types like 'u8'.
> > [2/6] Show the supported types on README of ftrace so
> >    that user application (e.g. perf) can check that.
> > [3/6] Add a type availability check to perf-probe.
> > [4/6] Add hexadecimal prefix support to perf-probe if
> >    it is supported by the kernel. 
> > [5/6] Change the perf-probe default type casting for
> >    unsigned type to hexadecimal (for backward compatibility)
> > [6/6] Change ftrace's 'uNN' to show value in decimal
> >    and use 'xNN' by default (for backward compatibility)
> > 
> > This way, we can also add "octal" type, pointer type,
> > and "character" type etc. and perf can check whether
> > the kernel supports it or not. :)
> 
> But this requires a kernel update... If we do it all in the tooling
> side, no kernel changes are required _and_ newer tools will work with
> older kernels, as this is just a formatting issue, the value is there
> and from its format one can infer its value, it is not even necessary to
> look at its "type".
> 
> I understand this is necessary for ftrace, because the pretty printer is
> in the kernel, but I don't see why we would prevent tooling from doing
> this pretty printing work and make it support any kernel.
> 
> I.e. no need at all for checking if the kernel supports anything, just
> pretty print it.

That's should be handled by libtraceevent. And if you need just
a pretty printing, you can do it in python/perl script via perf-script.
Anyway, to see the event parameters via perf tools, we have to use
perf-script with/without scripts. As you know, perf-script without
scripts, the output format depends on libtraceevent. And it seems that
the libtraceevent output depends on ftrace event "format" file.

And also as you can see in Naohiro's report　( https://lkml.org/lkml/2016/8/5/191 )
he was using perf-probe with ftrace trace_pipe interface, which was my
expected usecase. In that case we have to change ftrace side to
support various pretty printing.

IOW, perf only has very strong pretty printing interface - script
based output - for trace event arguments. For lighter use cases,
ftrace provide the print format.

So, I think this is a better meeting point, wouldn't you?

Thank you,


-- 
Masami Hiramatsu <mhiramat@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1465840

Em Fri, Aug 19, 2016 at 01:01:43AM +0900, Masami Hiramatsu escreveu:
> On Thu, 18 Aug 2016 11:14:42 -0300
> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:
> > > Hi Arnaldo and Steven,
> > > 
> > > Here is an RFC series of hexadecimal type casting and
> > > changing default type casting of perf and ftrace.
> > > 
> > > I've introduced x8,x16,x32,x64 according to previous
> > > discussion on LKML.
> > >   https://lkml.org/lkml/2016/8/10/339
> > > 
> > > This series includes not only adding hexadecimal types
> > > (x8,x16,x32,x64), but also checking it is supported by
> > > running kernel and keeping the backward compativility.
> > > 
> > > [1/6] Add hexadecimal type casting, but does not touch
> > >    existing types like 'u8'.
> > > [2/6] Show the supported types on README of ftrace so
> > >    that user application (e.g. perf) can check that.
> > > [3/6] Add a type availability check to perf-probe.
> > > [4/6] Add hexadecimal prefix support to perf-probe if
> > >    it is supported by the kernel. 
> > > [5/6] Change the perf-probe default type casting for
> > >    unsigned type to hexadecimal (for backward compatibility)
> > > [6/6] Change ftrace's 'uNN' to show value in decimal
> > >    and use 'xNN' by default (for backward compatibility)
> > > 
> > > This way, we can also add "octal" type, pointer type,
> > > and "character" type etc. and perf can check whether
> > > the kernel supports it or not. :)
> > 
> > But this requires a kernel update... If we do it all in the tooling
> > side, no kernel changes are required _and_ newer tools will work with
> > older kernels, as this is just a formatting issue, the value is there
> > and from its format one can infer its value, it is not even necessary to
> > look at its "type".
> > 
> > I understand this is necessary for ftrace, because the pretty printer is
> > in the kernel, but I don't see why we would prevent tooling from doing
> > this pretty printing work and make it support any kernel.
> > 
> > I.e. no need at all for checking if the kernel supports anything, just
> > pretty print it.
> 
> That's should be handled by libtraceevent. And if you need just
> a pretty printing, you can do it in python/perl script via perf-script.
> Anyway, to see the event parameters via perf tools, we have to use
> perf-script with/without scripts. As you know, perf-script without
> scripts, the output format depends on libtraceevent. And it seems that
> the libtraceevent output depends on ftrace event "format" file.
 
> And also as you can see in Naohiro's report　( https://lkml.org/lkml/2016/8/5/191 )
> he was using perf-probe with ftrace trace_pipe interface, which was my
> expected usecase. In that case we have to change ftrace side to
> support various pretty printing.

Sure, if one wants to have pretty printing via trace_pipe, then a kernel
reboot is needed, I'm talking about those who don't want to or can't
reboot their machines :-)

But anyway, your patches allow seeing those events in decimal for people
that can reboot their machine when that wasn't possible without extra
scripting via perl/python, a clear advance!

It remains to be coded a way to achieve the same result without
requiring a kernel reboot, i.e. a tooling only change.
 
> IOW, perf only has very strong pretty printing interface - script
> based output - for trace event arguments. For lighter use cases,
> ftrace provide the print format.
 
> So, I think this is a better meeting point, wouldn't you?

If upgrading the kernel is possible, yes.

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1466772

On Thu, 18 Aug 2016 13:13:21 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Fri, Aug 19, 2016 at 01:01:43AM +0900, Masami Hiramatsu escreveu:
> > On Thu, 18 Aug 2016 11:14:42 -0300
> > Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > 
> > > Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:
> > > > Hi Arnaldo and Steven,
> > > > 
> > > > Here is an RFC series of hexadecimal type casting and
> > > > changing default type casting of perf and ftrace.
> > > > 
> > > > I've introduced x8,x16,x32,x64 according to previous
> > > > discussion on LKML.
> > > >   https://lkml.org/lkml/2016/8/10/339
> > > > 
> > > > This series includes not only adding hexadecimal types
> > > > (x8,x16,x32,x64), but also checking it is supported by
> > > > running kernel and keeping the backward compativility.
> > > > 
> > > > [1/6] Add hexadecimal type casting, but does not touch
> > > >    existing types like 'u8'.
> > > > [2/6] Show the supported types on README of ftrace so
> > > >    that user application (e.g. perf) can check that.
> > > > [3/6] Add a type availability check to perf-probe.
> > > > [4/6] Add hexadecimal prefix support to perf-probe if
> > > >    it is supported by the kernel. 
> > > > [5/6] Change the perf-probe default type casting for
> > > >    unsigned type to hexadecimal (for backward compatibility)
> > > > [6/6] Change ftrace's 'uNN' to show value in decimal
> > > >    and use 'xNN' by default (for backward compatibility)
> > > > 
> > > > This way, we can also add "octal" type, pointer type,
> > > > and "character" type etc. and perf can check whether
> > > > the kernel supports it or not. :)
> > > 
> > > But this requires a kernel update... If we do it all in the tooling
> > > side, no kernel changes are required _and_ newer tools will work with
> > > older kernels, as this is just a formatting issue, the value is there
> > > and from its format one can infer its value, it is not even necessary to
> > > look at its "type".
> > > 
> > > I understand this is necessary for ftrace, because the pretty printer is
> > > in the kernel, but I don't see why we would prevent tooling from doing
> > > this pretty printing work and make it support any kernel.
> > > 
> > > I.e. no need at all for checking if the kernel supports anything, just
> > > pretty print it.
> > 
> > That's should be handled by libtraceevent. And if you need just
> > a pretty printing, you can do it in python/perl script via perf-script.
> > Anyway, to see the event parameters via perf tools, we have to use
> > perf-script with/without scripts. As you know, perf-script without
> > scripts, the output format depends on libtraceevent. And it seems that
> > the libtraceevent output depends on ftrace event "format" file.
>  
> > And also as you can see in Naohiro's report　( https://lkml.org/lkml/2016/8/5/191 )
> > he was using perf-probe with ftrace trace_pipe interface, which was my
> > expected usecase. In that case we have to change ftrace side to
> > support various pretty printing.
> 
> Sure, if one wants to have pretty printing via trace_pipe, then a kernel
> reboot is needed, I'm talking about those who don't want to or can't
> reboot their machines :-)
> 
> But anyway, your patches allow seeing those events in decimal for people
> that can reboot their machine when that wasn't possible without extra
> scripting via perl/python, a clear advance!
> 
> It remains to be coded a way to achieve the same result without
> requiring a kernel reboot, i.e. a tooling only change.

Hmm, one solution for user space tool is to identify the probed event
from event name, and decide output format based on the format locally
stored, like cached entries. Actually, current perf-probe to perf-script
execution chain lacks such kind of information, that is a problem.

 DWARF -> perf-probe -> ftrace -> perf-record -> perf-script

perf-probe can read DWARF(debuginfo) so it can handle a variety of types,
but between perf-probe to ftrace, it lacks type information and all
types falls into s8/16/32/64, u8/16/32/64, string and bitfield.
So after that process, perf-record treats data as a raw binary,
and perf-script tries to parse that binary based on ftrace's event
format. 

But if we can pass the data format in perf-cache entries like below

 DWARF -> perf-probe -> ftrace -> perf-record -+-> perf-script
                 +-------> probe-cache entry --+

then perf-probe can pass correct format to perf-script.

But anyway, I will update ftrace to add other types since that will
help ftrace users.
 
Thanks,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1465651

Em Thu, Aug 18, 2016 at 12:03:26PM -0400, Steven Rostedt escreveu:
> On Thu, 18 Aug 2016 17:57:32 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > Hi Arnaldo and Steven,
> > 
> 
> Arnaldo,
> 
> I acked all the patches with ftrace in the subject. You can take the
> series through your tree.

Ok!

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1465869

On Thu, 18 Aug 2016 17:57:32 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> Hi Arnaldo and Steven,
> 

Arnaldo,

I acked all the patches with ftrace in the subject. You can take the
series through your tree.

Thanks,

-- Steve

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web