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

Groups > linux.kernel > #1604206 > unrolled thread

[PATCH] stm class: Document the stm_ftrace

Back to article view | Back to linux.kernel

Contents

  [PATCH] stm class: Document the stm_ftrace Chunyan Zhang <chunyan.zhang@spreadtrum.com> - 2017-03-20 07:50 +0100
    Re: [PATCH] stm class: Document the stm_ftrace Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2017-03-20 10:20 +0100
      Re: [PATCH] stm class: Document the stm_ftrace Chunyan Zhang <zhang.lyra@gmail.com> - 2017-03-20 12:00 +0100
        Re: [PATCH] stm class: Document the stm_ftrace Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2017-03-20 12:20 +0100
          Re: [PATCH] stm class: Document the stm_ftrace Chunyan Zhang <zhang.lyra@gmail.com> - 2017-03-21 07:10 +0100
            Re: [PATCH] stm class: Document the stm_ftrace Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2017-03-21 08:40 +0100
              Re: [PATCH] stm class: Document the stm_ftrace Chunyan Zhang <zhang.lyra@gmail.com> - 2017-03-21 13:30 +0100

#1604206 — [PATCH] stm class: Document the stm_ftrace

This patch adds a description of the stm_ftrace device source, an
interface for collecting Function trace information via STM devices.

Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
---
 Documentation/trace/stm.txt | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
index 11cff47..7ec1c0e 100644
--- a/Documentation/trace/stm.txt
+++ b/Documentation/trace/stm.txt
@@ -83,7 +83,7 @@ by writing the name of the desired stm device there, for example:
 $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link
 
 For examples on how to use stm_source interface in the kernel, refer
-to stm_console or stm_heartbeat drivers.
+to stm_console, stm_heartbeat or stm_ftrace drivers.
 
 Each stm_source device will need to assume a master and a range of
 channels, depending on how many channels it requires. These are
@@ -107,5 +107,13 @@ console in the STP stream, create a "console" policy entry (see the
 beginning of this text on how to do that). When initialized, it will
 consume one channel.
 
+stm_ftrace
+==========
+
+This is another "stm_source" device, once the stm_ftrace is linked with
+an stm device, function address and parent function address which
+Ftrace subsystem would store into ring buffer will be exported via the
+stm device at the same time.
+
 [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf
 [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html
-- 
2.7.4

[toc] | [next] | [standalone]

#1604265

Hi Chunyan,

A couple of clarifications: iirc this applies to the function tracer
of ftrace, right? Does it make sense to mention that? Also, are you
planning to support other ftrace payloads like trace_printk()s?

Thanks,
--
Alex

On 20 March 2017 at 08:47, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote:
> This patch adds a description of the stm_ftrace device source, an
> interface for collecting Function trace information via STM devices.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
>  Documentation/trace/stm.txt | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
> index 11cff47..7ec1c0e 100644
> --- a/Documentation/trace/stm.txt
> +++ b/Documentation/trace/stm.txt
> @@ -83,7 +83,7 @@ by writing the name of the desired stm device there, for example:
>  $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link
>
>  For examples on how to use stm_source interface in the kernel, refer
> -to stm_console or stm_heartbeat drivers.
> +to stm_console, stm_heartbeat or stm_ftrace drivers.
>
>  Each stm_source device will need to assume a master and a range of
>  channels, depending on how many channels it requires. These are
> @@ -107,5 +107,13 @@ console in the STP stream, create a "console" policy entry (see the
>  beginning of this text on how to do that). When initialized, it will
>  consume one channel.
>
> +stm_ftrace
> +==========
> +
> +This is another "stm_source" device, once the stm_ftrace is linked with
> +an stm device, function address and parent function address which
> +Ftrace subsystem would store into ring buffer will be exported via the
> +stm device at the same time.
> +
>  [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf
>  [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html
> --
> 2.7.4
>

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

#1604371

Hi Alex,

On 20 March 2017 at 16:49, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Hi Chunyan,
>
> A couple of clarifications: iirc this applies to the function tracer
> of ftrace, right? Does it make sense to mention that? Also, are you

Right, only applies to the function tracer currently (actually only
function address and parent function address of Function tracer is
recorded into STM, I mean it doesn't include like "pid" "task name"
"cpu-id" these information right now). It makes sense to mention
function tracer, I will address that.

> planning to support other ftrace payloads like trace_printk()s?

No plan so far, but I think I can consider to do that, it depends on
how many people think that are helpful.
What do you think?

Thanks,
Chunyan

>
> Thanks,
> --
> Alex
>
> On 20 March 2017 at 08:47, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote:
>> This patch adds a description of the stm_ftrace device source, an
>> interface for collecting Function trace information via STM devices.
>>
>> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
>> ---
>>  Documentation/trace/stm.txt | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
>> index 11cff47..7ec1c0e 100644
>> --- a/Documentation/trace/stm.txt
>> +++ b/Documentation/trace/stm.txt
>> @@ -83,7 +83,7 @@ by writing the name of the desired stm device there, for example:
>>  $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link
>>
>>  For examples on how to use stm_source interface in the kernel, refer
>> -to stm_console or stm_heartbeat drivers.
>> +to stm_console, stm_heartbeat or stm_ftrace drivers.
>>
>>  Each stm_source device will need to assume a master and a range of
>>  channels, depending on how many channels it requires. These are
>> @@ -107,5 +107,13 @@ console in the STP stream, create a "console" policy entry (see the
>>  beginning of this text on how to do that). When initialized, it will
>>  consume one channel.
>>
>> +stm_ftrace
>> +==========
>> +
>> +This is another "stm_source" device, once the stm_ftrace is linked with
>> +an stm device, function address and parent function address which
>> +Ftrace subsystem would store into ring buffer will be exported via the
>> +stm device at the same time.
>> +
>>  [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf
>>  [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html
>> --
>> 2.7.4
>>

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

#1604404

Chunyan Zhang <zhang.lyra@gmail.com> writes:

> Hi Alex,
>
> On 20 March 2017 at 16:49, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
>> Hi Chunyan,
>>
>> A couple of clarifications: iirc this applies to the function tracer
>> of ftrace, right? Does it make sense to mention that? Also, are you
>
> Right, only applies to the function tracer currently (actually only
> function address and parent function address of Function tracer is
> recorded into STM, I mean it doesn't include like "pid" "task name"
> "cpu-id" these information right now). It makes sense to mention
> function tracer, I will address that.

Thanks!

>> planning to support other ftrace payloads like trace_printk()s?
>
> No plan so far, but I think I can consider to do that, it depends on
> how many people think that are helpful.
> What do you think?

Well, I myself almost never use function tracer, but I do use
tracepoints/trace_printk()s. I'm *guessing* that everybody who's
subsystem implement tracepoints will be interested in those.

I confess that I haven't yet looked at the code properly, so I'm a don't
have a picture of what it will take to implement these.

Regards,
--
Alex

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

#1605325

On 20 March 2017 at 19:09, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Chunyan Zhang <zhang.lyra@gmail.com> writes:
>
>> Hi Alex,
>>
>> On 20 March 2017 at 16:49, Alexander Shishkin
>> <alexander.shishkin@linux.intel.com> wrote:
>>> Hi Chunyan,
>>>
>>> A couple of clarifications: iirc this applies to the function tracer
>>> of ftrace, right? Does it make sense to mention that? Also, are you
>>
>> Right, only applies to the function tracer currently (actually only
>> function address and parent function address of Function tracer is
>> recorded into STM, I mean it doesn't include like "pid" "task name"
>> "cpu-id" these information right now). It makes sense to mention
>> function tracer, I will address that.
>
> Thanks!
>
>>> planning to support other ftrace payloads like trace_printk()s?
>>
>> No plan so far, but I think I can consider to do that, it depends on
>> how many people think that are helpful.
>> What do you think?
>
> Well, I myself almost never use function tracer, but I do use
> tracepoints/trace_printk()s. I'm *guessing* that everybody who's

In fact I had implemented exporting tracepoints to STM and tried
upstreaming that, but Steven Rostedt and Ingo expressed their worries
on that would introduce a considerable impact on Ftrace fast path
since a tracepoint basically was a string which was too long to be
written to STM with some acceptable impact on fast path, so I stopped
upstreaming that feature.

Thanks,
Chunyan

> subsystem implement tracepoints will be interested in those.
>
> I confess that I haven't yet looked at the code properly, so I'm a don't
> have a picture of what it will take to implement these.
>
> Regards,
> --
> Alex

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

#1605366

On 21 March 2017 at 07:57, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
> On 20 March 2017 at 19:09, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
>> Chunyan Zhang <zhang.lyra@gmail.com> writes:
>>
>>> Hi Alex,
>>>
>>> On 20 March 2017 at 16:49, Alexander Shishkin
>>> <alexander.shishkin@linux.intel.com> wrote:
>>>> Hi Chunyan,
>>>>
>>>> A couple of clarifications: iirc this applies to the function tracer
>>>> of ftrace, right? Does it make sense to mention that? Also, are you
>>>
>>> Right, only applies to the function tracer currently (actually only
>>> function address and parent function address of Function tracer is
>>> recorded into STM, I mean it doesn't include like "pid" "task name"
>>> "cpu-id" these information right now). It makes sense to mention
>>> function tracer, I will address that.
>>
>> Thanks!
>>
>>>> planning to support other ftrace payloads like trace_printk()s?
>>>
>>> No plan so far, but I think I can consider to do that, it depends on
>>> how many people think that are helpful.
>>> What do you think?
>>
>> Well, I myself almost never use function tracer, but I do use
>> tracepoints/trace_printk()s. I'm *guessing* that everybody who's
>
> In fact I had implemented exporting tracepoints to STM and tried
> upstreaming that, but Steven Rostedt and Ingo expressed their worries
> on that would introduce a considerable impact on Ftrace fast path
> since a tracepoint basically was a string which was too long to be
> written to STM with some acceptable impact on fast path, so I stopped
> upstreaming that feature.

Did we ever consider writing a string pointer (or even on offset into
the corresponding section, to avoid KASLR fun) instead of the actual
string? This would require a kernel binary on the decoding end,
though.

Regards,
--
Alex

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

#1605558

On 21 March 2017 at 15:33, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> On 21 March 2017 at 07:57, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
>> On 20 March 2017 at 19:09, Alexander Shishkin
>> <alexander.shishkin@linux.intel.com> wrote:
>>> Chunyan Zhang <zhang.lyra@gmail.com> writes:
>>>
>>>> Hi Alex,
>>>>
>>>> On 20 March 2017 at 16:49, Alexander Shishkin
>>>> <alexander.shishkin@linux.intel.com> wrote:
>>>>> Hi Chunyan,
>>>>>
>>>>> A couple of clarifications: iirc this applies to the function tracer
>>>>> of ftrace, right? Does it make sense to mention that? Also, are you
>>>>
>>>> Right, only applies to the function tracer currently (actually only
>>>> function address and parent function address of Function tracer is
>>>> recorded into STM, I mean it doesn't include like "pid" "task name"
>>>> "cpu-id" these information right now). It makes sense to mention
>>>> function tracer, I will address that.
>>>
>>> Thanks!
>>>
>>>>> planning to support other ftrace payloads like trace_printk()s?
>>>>
>>>> No plan so far, but I think I can consider to do that, it depends on
>>>> how many people think that are helpful.
>>>> What do you think?
>>>
>>> Well, I myself almost never use function tracer, but I do use
>>> tracepoints/trace_printk()s. I'm *guessing* that everybody who's
>>
>> In fact I had implemented exporting tracepoints to STM and tried
>> upstreaming that, but Steven Rostedt and Ingo expressed their worries
>> on that would introduce a considerable impact on Ftrace fast path
>> since a tracepoint basically was a string which was too long to be
>> written to STM with some acceptable impact on fast path, so I stopped
>> upstreaming that feature.
>
> Did we ever consider writing a string pointer (or even on offset into

Regarding to the pointer, you mean event pointer in Ftrace ring
buffer? I considered recording trace_events' ring buffer address which
their meta data is stored, my concern was how we should do if ring
buffer overwriting happened.

> the corresponding section, to avoid KASLR fun) instead of the actual
> string? This would require a kernel binary on the decoding end,
> though.

Decoding function traces supported currently from STM also needs
kernel binary :)

Thanks,
Chunyan

>
> Regards,
> --
> Alex

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web