* David Ahern <dsahern@xxxxxxxxx> wrote: > On 9/12/14, 2:44 PM, Arnaldo Carvalho de Melo wrote: > >Em Fri, Sep 12, 2014 at 10:37:39AM -0700, David Ahern escreveu: > >>On 9/12/14, 4:48 AM, Pawel Moll wrote: > >>>This patch adds a PERF_COUNT_SW_MARKER event type, which > >>>can be requested by user and a PERF_EVENT_IOC_MARKER > >>>ioctl command which will inject an event of said type into > >>>the perf buffer. The ioctl can take a zero-terminated > >>>string argument, similar to tracing_marker in ftrace, > >>>which will be kept in the "raw" field of the sample. > >>> > >>>The main use case for this is synchronisation of > >>>performance data generated in user space with the perf > >>>stream coming from the kernel. For example, the marker > >>>can be inserted by a JIT engine after it generated > >>>portion of the code, but before the code is executed > >>>for the first time, allowing the post-processor to > >>>pick the correct debugging information. Other example > >>>is a system profiling tool taking data from other > >>>sources than just perf, which generates a marker > >>>at the beginning at at the end of the session > >>>(also possibly periodically during the session) to > >>>synchronise kernel timestamps with clock values > >>>obtained in userspace (gtod or raw_monotonic). > >> > >>Seems really similar to what I proposed in the past: > >> > >>https://lkml.org/lkml/2011/2/27/159 > >> > >>Which was rejected. > > > >I took a look at that thread, but just barely, emphasis on that. > > > >Injecting something from userspace, a la ftrace, seems to be something, > >as tglx mentioned, "buried" in that patchset. > > Thomas object to an ioctl buried deep in a patch -- newbie > mistake. > > Peter objected to the ioctl https://lkml.org/lkml/2011/3/1/229 > > It was not userspace injecting random data into the stream but > rather forcing the sample to be generated and added to the > stream. I think adding an ioctl to inject user-provided data into the event stream is sensible, as long as there's a separate 'user generated data' event for it, etc. The main usecase I could see would be to introduce a perf_printf() variant, supported by 'perf trace' by default, to add various tracable printouts to apps. Timestamps generated by apps would be another usecase. It would probably be wise to add a 32-bit (or 64-bit) message type ID, plus a length field, with a message type registry somewhere in tools/perf/ (and reference implementation for each new subtype), to keep things organized yet flexible going forward. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
