Ftrace Data Export
Hi Chunyan,
When you wrote your patchset to provide ftrace exports, why did you choose to export only function trace? Why not tracepoints, function_graph, hwlat, irqsoff and all the other possibilities?
Is there an underlying reason why you chose to export only function trace?
Thanks
Signature · 1 line
balbi
Hi Felipe,
Quoted 5 lines · Felipe Balbi
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.
Quoted 1 line
function_graph, hwlat, irqsoff and all the other possibilities?
I haven't thought about these clear enough :)
Any suggestion?
Thanks,
Chunyan
[1] https://lkml.org/lkml/2015/7/7/230
Quoted 8 lines
Is there an underlying reason why you chose to export only function trace?
Thanks
--
balbi
Hi,
(sorry for the long delay, just back from vacations)
Quoted 16 lines · Chunyan Zhang
Hi Felipe,
Quoted 5 lines · Felipe Balbi
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.
Quoted 2 lines
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?
Quoted 4 lines
Quoted 1 line
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.
Quoted 1 line
hmm, lkml.org seems to be down.
Signature · 1 line
balbi
Quoted 22 lines · Felipe Balbi
Hi,
(sorry for the long delay, just back from vacations)
Quoted 16 lines · Chunyan Zhang
Hi Felipe,
Quoted 5 lines · Felipe Balbi
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.
Quoted 4 lines
Quoted 2 lines
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 :)
Quoted 3 lines
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 :-(
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 7 lines
Quoted 2 lines
hmm, lkml.org seems to be down.
--
balbi
Hi,
Quoted 7 lines · Chunyan Zhang
Quoted 2 lines
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
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 7 lines
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.
Signature · 1 line
balbi