Re: Ftrace Data Export

[Felipe Balbi <felipe.balbi@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]


Hi,

(sorry for the long delay, just back from vacations)

Chunyan Zhang <zhang.chunyan@linaro.org> writes:
> Hi Felipe,
>
> On 17 May 2017 at 16:08, Felipe Balbi <felipe.balbi@linux.intel.com> wrote:
>>
>> Hi Chunyan,
>>
>> When you wrote your patchset to provide ftrace exports, why did you
>> choose to export only function trace? Why not tracepoints,
>
> In fact, I tried submitting patches[1] to do exporting tracepoint to
> STM, but Ingo and Steven commented that would introduce certain amount
> of overhead, and that was not acceptable. I also used
> 'benchmark_event' to see the additional overhead caused by printing
> tracepoint message to STM.  I cannot remember the exact data though,
> the increased time consuming indeed was non-ignorable.
>
> So at the end I gave up that idea, and later on switched to the way of
> implementation you see in the kernel now.

Were you decoding the data before off-loading it to the trace export?

Maybe that's why they consider it an extra overhead? Have you considered
off-loading raw data for further post processing?

>> function_graph, hwlat, irqsoff and all the other possibilities?
>
> I haven't thought about these clear enough :)
> Any suggestion?

I think we should be able to export everything and anything :-p But, of
course, we would need tooling to decode it after the fact.

> [1] https://lkml.org/lkml/2015/7/7/230

hmm, lkml.org seems to be down.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]