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