Messages in this thread | | | Date | Thu, 18 Aug 2016 13:13:21 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting |
| |
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
| |