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

Groups > linux.kernel > #1656115 > unrolled thread

Re: Ftrace Data Export

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Ftrace Data Export Felipe Balbi <felipe.balbi@linux.intel.com> - 2017-06-02 12:30 +0200
    Re: Ftrace Data Export Chunyan Zhang <zhang.chunyan@linaro.org> - 2017-06-02 14:30 +0200
      Re: Ftrace Data Export Felipe Balbi <felipe.balbi@linux.intel.com> - 2017-06-05 08:20 +0200

#1656115 — Re: Ftrace Data Export

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1656176

On 2 June 2017 at 18:24, Felipe Balbi <felipe.balbi@linux.intel.com> wrote:
>
> 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?

Indeed :)

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

Yes, that's also the way off-loading function trace has been implemented now.
And like you said below, I also believe we can do the similar things
to other tracers.
I'd like to do this, but I have some other tasks in hands recently :-(

>
>>> 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.

Yes, tools for decoding these raw data with kernel binary is one
thing, and how large storage STM can use to collect traces will also
affect how much value doing this will bring in and perhaps will
influence how we implement off-loading ftrace to trace export.

Since I haven't played Intel STM, how large are the storages connected
to STM on Intel platforms in general?

Thanks,
Chunyan

>
>> [1] https://lkml.org/lkml/2015/7/7/230
>
> hmm, lkml.org seems to be down.
>
> --
> balbi

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

#1657295

[Multipart message — attachments visible in raw view] — view raw

Hi,

Chunyan Zhang <zhang.chunyan@linaro.org> writes:
>> Maybe that's why they consider it an extra overhead? Have you considered
>> off-loading raw data for further post processing?
>
> Yes, that's also the way off-loading function trace has been implemented now.
> And like you said below, I also believe we can do the similar things
> to other tracers.
> I'd like to do this, but I have some other tasks in hands recently :-(

fair enough

>>>> 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.
>
> Yes, tools for decoding these raw data with kernel binary is one
> thing, and how large storage STM can use to collect traces will also
> affect how much value doing this will bring in and perhaps will
> influence how we implement off-loading ftrace to trace export.
>
> Since I haven't played Intel STM, how large are the storages connected
> to STM on Intel platforms in general?

that I don't know :-) My interest here is to off-load it via USB. I
suppose Alex knows the size of STM storage on Intel systems.

-- 
balbi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web