On Thu, Nov 06, 2014 at 04:51:57PM +0000, Pawel Moll wrote: > This patch adds a PR_TASK_PERF_UEVENT prctl call which can be used by > any process to inject custom data into perf data stream as a new > PERF_RECORD_UEVENT record, if such process is being observed or if it > is running on a CPU being observed by the perf framework. > > The prctl call takes the following arguments: > > prctl(PR_TASK_PERF_UEVENT, type, size, data, flags); > > - type: a number meaning to describe content of the following data. > Kernel does not pay attention to it and merely passes it further in > the perf data, therefore its use must be agreed between the events > producer (the process being observed) and the consumer (performance > analysis tool). The perf userspace tool will contain a repository of > "well known" types and reference implementation of their decoders. > - size: Length in bytes of the data. > - data: Pointer to the data. > - flags: Reserved for future use. Always pass zero. > > Perf context that are supposed to receive events generated with the > prctl above must be opened with perf_event_attr.uevent set to 1. The > PERF_RECORD_UEVENT records consist of a standard perf event header, > 32-bit type value, 32-bit data size and the data itself, followed by > padding to align the overall record size to 8 bytes and optional, > standard sample_id field. > > Example use cases: > > - "perf_printf" like mechanism to add logging messages to perf data; > in the simplest case it can be just > > prctl(PR_TASK_PERF_UEVENT, 0, 8, "Message", 0); > > - 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. > The think I remember being raised was a unified means of these msgs across perf/ftrace/lttng. I am not seeing that mentioned. Also, I would like a stronger rationale for the @type argument, if it has no actual meaning why is it separate from the binary msg data? -- 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
