On 21 March 2017 at 15:33, Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: > On 21 March 2017 at 07:57, Chunyan Zhang <zhang.lyra@xxxxxxxxx> wrote: >> On 20 March 2017 at 19:09, Alexander Shishkin >> <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: >>> Chunyan Zhang <zhang.lyra@xxxxxxxxx> writes: >>> >>>> Hi Alex, >>>> >>>> On 20 March 2017 at 16:49, Alexander Shishkin >>>> <alexander.shishkin@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
