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

On Fri, 2014-09-12 at 17:19 +0100, Arnaldo Carvalho de Melo wrote:

Em Fri, Sep 12, 2014 at 02:58:55PM +0100, Pawel Moll escreveu:

quoted

On Fri, 2014-09-12 at 14:49 +0100, Arnaldo Carvalho de Melo wrote:

quoted

Perhaps both? I.e. an u64 followed from a string, if the u64 is zero,
then there is a string right after it?

quoted

How would this look like in userspace? Something like this?

quoted

8<----
struct perf_event_marker {
	uint64_t value;
	char *string;
} arg;

quoted

arg.value = 0x1234;

quoted

/* or */

quoted

arg.value = 0;
arg.string = "abcd";

quoted

ioctl(fd, PERF_EVENT_IOC_MARKER, &arg)
8<----

quoted

If so, maybe it would simpler just to go for classic size/data
structure?

quoted

8<-----
struct perf_event_marker {
	uint32_t size;
	void *data;
}
8<-----

quoted

This would directly map into struct perf_raw_record...

I can see the usefulness of having it all, i.e. if we do just:

perf trace --pid `pidof some-tool-in-debug-mode-using-this-interface`

Hm. I haven't thought about a situation when 3rd party wants to inject
something into "my" data stream... I guess it could be implemented (a
"pid" member of the struct perf_event_marker with default 0 meaning
"myself"?), but will definitely complicate the patch. Should I have a
look at it now or maybe leave it till we get a general agreement about
the marker ioctl existence?

Then 'perf trace' doesn't know about any binary format a tool may have,
getting strings there (hey, LD_PRELOADing some logging library to hook
into this comes to mind) and having it merged with other events
(syscalls, pagefaults, etc) looks useful.

But do you still mean a "magic" u64 before the rest? Injecting a string
would just mean:

	marker.size = strlen(s) + 1;
	marker.data = s;

As well as some specialized version of 'perf trace' that knows about
some binary protocol that would get app specific stats or lock status,
etc, perhaps even plugins for 'perf trace' that would be selected by
that first u64? Also seems useful.
	  
I.e. having a way to provide just strings and another that would allow
passing perf_raw_record.

Sounds interesting. But then maybe this stuff shouldn't go into "raw"
then? It could be something like this in the sample:

	{ u64 type; /* 0 means zero-terminated string in data */
	  u32 size;
	  char data[size]; } && PERF_SAMPLE_MARKER

Pawel