Re: [RFC 2/2] perf: Marker software event and ioctl

* David Ahern [off-list ref] wrote:

On 9/12/14, 2:44 PM, Arnaldo Carvalho de Melo wrote:

quoted

Em Fri, Sep 12, 2014 at 10:37:39AM -0700, David Ahern escreveu:

quoted

On 9/12/14, 4:48 AM, Pawel Moll wrote:

quoted

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