Re: [PATCH v2 2/2] perf: Userspace event
From: Ingo Molnar
Date: Wed Sep 24 2014 - 03:20:27 EST
* Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> On Tue, 23 Sep 2014 18:03:07 +0100, Pawel Moll wrote:
> > This patch adds a new PERF_COUNT_SW_UEVENT software event
> > and a related PERF_SAMPLE_UEVENT sample. User can now
> > write to the the perf file descriptor, injecting such
> > event in the perf buffer.
> It seems the PERF_SAMPLE_UEVENT sample can be injected to any event. So
> why the PERF_COUNT_SW_UEVENT is needed? At least one can use the
> SW_DUMMY event for that purpose.
> Also I think it'd be better to be a record type (PERF_RECORD_XXX)
> instead of a sample flag (PERF_SAMPLE_XXX). In perf tools, we already
> use perf_user_event_type for synthesized userspace events. This way it
> can avoid unnecessary sample processing for userspace events.
> For contents, I prefer to give complete control to users - kernel
> doesn't need to care about it other than its size. If one just wants to
> use strings only, she can write them directly. If others want to mix
> different types of data, they might need to define a data format for
> their use.
It would also be nice to add support for this to tools/perf/ (so
that 'trace' displays such entries in a perf.data), with a
minimum testcase for 'perf test' as well.
Perhaps also add a small sub-utility to inject such events from
the command line, such as:
trace user-event "this is a test message"
('trace' is a shortcut command for 'perf trace'.)
It would have a usecase straight away: perf could be used to
easily trace script execution for example.
For that probably another mode of user event generation would be
needed as well: a process that has no access to any perf fds
should still be able to generate user events, if the
profiling/tracing context has permitted that. In this case we'd
inject the event either into the first, or all currently active
events (but only once per output buffer, or so).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/