Re: [RFC 00/14] perf tools: Introduce new 'ftrace' command

[zhangwei(Jovi)]

On 2013/4/24 17:52, Namhyung Kim wrote:
> Hi Ingo,
> 
> On Wed, 24 Apr 2013 08:50:18 +0200, Ingo Molnar wrote:
>> * Pekka Enberg <penberg@xxxxxxxxxx> wrote:
>>
>>> Hello,
>>>
>>> On Tue, 2013-04-23 at 17:30 +0900, Namhyung Kim wrote:
>>>>> This patchset implements a front-end tool for kernel's ftrace.  It
>>>>> uses function_graph tracer by default and normal function tracer is
>>>>> also supported.  (Of course you need to enable those tracers in your
>>>>> kernel first.)
>>>
>>> On Tue, Apr 23, 2013 at 6:58 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>>>> Very nice Namhyung, thanks for doing this. I did a quick run through of
>>>> the patches and I have no complaints about them. I'm not sure how the
>>>> others will feel about it.
>>>
>>> I also skimmed through the patches and they look like a reasonable
>>> starting point. So FWIW,
>>>
>>> Acked-by: Pekka Enberg <penberg@xxxxxxxxxx>
>>>
>>> Are there any plans in trying to consolidate 'perf trace' and this? As
>>> a user I don't really care what the underlying mechanism and would
>>> like things to just work out of the box.
>>
>> Exactly. I'd love to see ftrace and perf trace unified.
>>
>> I have no objections against having a 'perf ftrace' interim step - as long 
>> as it's really a temporary migration construct, not something we intend to 
>> keep forever.
> 
> Hmm.. okay.
> 
> I think it'd be great if perf trace can cover both of kernel and user
> spaces.  But function tracing in userspace looks impossible IMHO.
> 
> So how about changing perf trace to receive proposed sub-commands
> (live/record/show/report) and following options:
> 
>   --kernel::	do ftrace (for kernel functions)
>   --syscall::	do system call tracing (what perf trace does now)
> 
"--kernel" make me think it's will trace all event tracepoints, not only ftrace.

for "--syscall" option, I always think we should enhance syscall tracing more than now,
like use annotate info when parse syscall event in perf, as other tracepoint does.
we also need read filename user string in kernel space when open syscall tracepoint hit,
record in perf.data, then perf parse it. After these functionality is implemented,
we will don't need a separate syscall tracing tool in perf any more,
just use: perf record -e "syscalls:" -a
> 
> But I think we need to have an agreement on the file/directory format to
> support multiple recorder threads first.  Any comments on this issue?
> 
> Thanks,
> Namhyung
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/