[PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Xiao Guangrong]

'inject' event is a very useful feature and it's suggested by Ingo
[ See http://lkml.org/lkml/2009/12/28/31 ]

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
---
 include/linux/perf_event.h  |   13 +++++++++++
 kernel/perf_event.c         |   47 +++++++++++++++++++++++++++++++++++++++++++
 tools/perf/builtin-record.c |   13 +++++++++++
 tools/perf/util/session.c   |    5 ++++
 tools/perf/util/session.h   |    3 +-
 5 files changed, 80 insertions(+), 1 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9a1d276..6c93f88 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -228,6 +228,7 @@ struct perf_event_attr {
 #define PERF_EVENT_IOC_PERIOD		_IOW('$', 4, __u64)
 #define PERF_EVENT_IOC_SET_OUTPUT	_IO ('$', 5)
 #define PERF_EVENT_IOC_SET_FILTER	_IOW('$', 6, char *)
+#define PERF_EVENT_IOC_INJECT		_IO ('$', 7)
 
 enum perf_event_ioc_flags {
 	PERF_IOC_FLAG_GROUP		= 1U << 0,
@@ -413,10 +414,22 @@ enum perf_event_type {
 	 * };
 	 */
 	PERF_RECORD_SAMPLE		= 9,
+	/*
+	 * struct {
+	 *	struct perf_event_header	header;
+	 *	u32 inject_event_id;
+	 * 	u64 value;
+	 * };
+	 */
+	PERF_RECORD_INJECT		= 10,
 
 	PERF_RECORD_MAX,			/* non-ABI */
 };
 
+enum perf_inject_event {
+	PERF_INJECT_HZ = 0x01,
+};
+
 enum perf_callchain_context {
 	PERF_CONTEXT_HV			= (__u64)-32,
 	PERF_CONTEXT_KERNEL		= (__u64)-128,
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 8984afd..9343c6c 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -2012,6 +2012,50 @@ unlock:
 	return ret;
 }
 
+static int perf_inject_get_hz(u64 *hz)
+{
+	*hz = HZ;
+	return 0;
+}
+
+static int perf_inject_event(struct perf_event *event, u32 inject_event_id,
+			     int (*get_value)(u64 *))
+{
+	struct perf_output_handle handle;
+	struct perf_inject_event {
+		struct perf_event_header header;
+		u32 inject_event_id;
+		u64 value;
+	} inject_event;
+	int ret = 0;
+
+	inject_event.header.type = PERF_RECORD_INJECT;
+	inject_event.header.misc = 0;
+	inject_event.header.size = sizeof(inject_event);
+	inject_event.inject_event_id = inject_event_id;
+
+	ret = get_value(&inject_event.value);
+	if (ret)
+		goto exit;
+
+	ret = perf_output_begin(&handle, event, inject_event.header.size, 0, 0);
+	if (ret)
+		goto exit;
+
+	perf_output_put(&handle, inject_event);
+	perf_output_end(&handle);
+exit:
+	return ret;
+}
+
+static int perf_inject_ioctl(struct perf_event *event, unsigned int arg)
+{
+	if (!arg || arg & ~PERF_INJECT_HZ)
+		return -EINVAL;
+
+	return perf_inject_event(event, PERF_INJECT_HZ, perf_inject_get_hz);
+}
+
 static int perf_event_set_output(struct perf_event *event, int output_fd);
 static int perf_event_set_filter(struct perf_event *event, void __user *arg);
 
@@ -2044,6 +2088,9 @@ static long perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 	case PERF_EVENT_IOC_SET_FILTER:
 		return perf_event_set_filter(event, (void __user *)arg);
 
+	case PERF_EVENT_IOC_INJECT:
+		return perf_inject_ioctl(event, arg);
+
 	default:
 		return -ENOTTY;
 	}
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2654253..d13601d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -65,6 +65,8 @@ static int			file_new			=      1;
 
 static struct perf_session	*session;
 
+u32 inject_events;
+
 struct mmap_data {
 	int			counter;
 	void			*base;
@@ -381,6 +383,17 @@ try_again:
 		}
 	}
 
+	if (inject_events) {
+		ret = ioctl(fd[nr_cpu][counter], PERF_EVENT_IOC_INJECT,
+			    inject_events);
+		if (ret) {
+			error("failed to inject event(%u) with %d (%s)\n",
+			      inject_events, errno, strerror(errno));
+			exit(-1);
+		}
+		inject_events = 0;
+	}
+
 	ioctl(fd[nr_cpu][counter], PERF_EVENT_IOC_ENABLE);
 }
 
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 7f0537d..74f43af 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -179,6 +179,8 @@ static void perf_event_ops__fill_defaults(struct perf_event_ops *handler)
 		handler->throttle = process_event_stub;
 	if (handler->unthrottle == NULL)
 		handler->unthrottle = process_event_stub;
+	if (handler->inject == NULL)
+		handler->inject = process_event_stub;
 }
 
 static const char *event__name[] = {
@@ -192,6 +194,7 @@ static const char *event__name[] = {
 	[PERF_RECORD_FORK]	 = "FORK",
 	[PERF_RECORD_READ]	 = "READ",
 	[PERF_RECORD_SAMPLE]	 = "SAMPLE",
+	[PERF_RECORD_INJECT]	 = "INJECT",
 };
 
 unsigned long event__total[PERF_RECORD_MAX];
@@ -239,6 +242,8 @@ static int perf_session__process_event(struct perf_session *self,
 		return ops->throttle(event, self);
 	case PERF_RECORD_UNTHROTTLE:
 		return ops->unthrottle(event, self);
+	case PERF_RECORD_INJECT:
+		return ops->inject(event, self);
 	default:
 		self->unknown_events++;
 		return -1;
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index 77c5ee2..8742354 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -40,7 +40,8 @@ struct perf_event_ops {
 		 lost,
 		 read,
 		 throttle,
-		 unthrottle;
+		 unthrottle,
+		 inject;
 };
 
 struct perf_session *perf_session__new(const char *filename, int mode, bool force);
-- 
1.6.1.2

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Stijn Devriendt]

> 'inject' event is a very useful feature and it's suggested by Ingo
> [ See http://lkml.org/lkml/2009/12/28/31 ]

Is it possible to, instead of injecting a specific inject_event enum,
pass a type/config pair (+task/cpu?) to inject the value of that
specific event? Then the HZ could have it's own perf_event type.

This integrates better with what I'm struggling with right now:
counters that are not ever incrementing but rather indicate
a discrete value inside the kernel that might change both
up and down. My dynticks knowledge is rather limited but
if HZ might vary then this approach is definately worth it.

Regards,
Stijn

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Xiao Guangrong]

Stijn Devriendt wrote:
>> 'inject' event is a very useful feature and it's suggested by Ingo
>> [ See http://lkml.org/lkml/2009/12/28/31 ]
> 
> Is it possible to, instead of injecting a specific inject_event enum,
> pass a type/config pair (+task/cpu?) to inject the value of that
> specific event? Then the HZ could have it's own perf_event type.
> 

Until now, 'inject' event just trigger parameter/query events, if
you need sample cpu/task, you can use other event.

> This integrates better with what I'm struggling with right now:
> counters that are not ever incrementing but rather indicate
> a discrete value inside the kernel that might change both
> up and down. My dynticks knowledge is rather limited but
> if HZ might vary then this approach is definately worth it.
> 

dynticks not touch HZ at all as i know.

Thanks,
Xiao

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Peter Zijlstra]

On Tue, 2009-12-29 at 13:21 +0800, Xiao Guangrong wrote:
> 'inject' event is a very useful feature and it's suggested by Ingo
> [ See http://lkml.org/lkml/2009/12/28/31 ]

I really dislike the name, event injection to me would be like a write()
interface where you provide the actual event data to be stuffed in the
output stream.

This just seems like a very weird way of getting data out. A kind of
like sysconf() but done very strange.

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, 2009-12-29 at 13:21 +0800, Xiao Guangrong wrote:
> > 'inject' event is a very useful feature and it's suggested by Ingo
> > [ See http://lkml.org/lkml/2009/12/28/31 ]
> 
> I really dislike the name, event injection to me would be like a write() 
> interface where you provide the actual event data to be stuffed in the 
> output stream.
> 
> This just seems like a very weird way of getting data out. A kind of like 
> sysconf() but done very strange.

What kind of API would you suggest?

	Ingo

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Peter Zijlstra]

On Wed, 2009-12-30 at 10:28 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Tue, 2009-12-29 at 13:21 +0800, Xiao Guangrong wrote:
> > > 'inject' event is a very useful feature and it's suggested by Ingo
> > > [ See http://lkml.org/lkml/2009/12/28/31 ]
> > 
> > I really dislike the name, event injection to me would be like a write() 
> > interface where you provide the actual event data to be stuffed in the 
> > output stream.
> > 
> > This just seems like a very weird way of getting data out. A kind of like 
> > sysconf() but done very strange.
> 
> What kind of API would you suggest?

sysconf() seems ideal for getting single, mostly constant variables out
of the kernel, we already have non POSIX (read Linux specific) names in
there.

_SC_KERNEL_RELOCATION_OFFSET
_SC_KERNEL_HZ

or somethings like that comes to mind.

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Xiao Guangrong]

Peter Zijlstra wrote:
> On Tue, 2009-12-29 at 13:21 +0800, Xiao Guangrong wrote:
>> 'inject' event is a very useful feature and it's suggested by Ingo
>> [ See http://lkml.org/lkml/2009/12/28/31 ]
> 
> I really dislike the name, event injection to me would be like a write()
> interface where you provide the actual event data to be stuffed in the
> output stream.
> 

Yes, it like write and it writes something form kernel to perf.
And, i think this name is suitable for it's doing that injects an
'artificial' event, it's well if you have other name for it :-)

> This just seems like a very weird way of getting data out. A kind of
> like sysconf() but done very strange.
> 

It's since some parameter is only used by perf, suce as HZ in this patch and
'relocation offset' in my other patchset, it also well if has better way to
do it :-)

Thanks,
Xiao

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2009-12-30 at 10:28 +0100, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Tue, 2009-12-29 at 13:21 +0800, Xiao Guangrong wrote:
> > > > 'inject' event is a very useful feature and it's suggested by Ingo
> > > > [ See http://lkml.org/lkml/2009/12/28/31 ]
> > > 
> > > I really dislike the name, event injection to me would be like a write() 
> > > interface where you provide the actual event data to be stuffed in the 
> > > output stream.
> > > 
> > > This just seems like a very weird way of getting data out. A kind of like 
> > > sysconf() but done very strange.
> > 
> > What kind of API would you suggest?
> 
> sysconf() seems ideal for getting single, mostly constant variables out
> of the kernel, we already have non POSIX (read Linux specific) names in
> there.
> 
> _SC_KERNEL_RELOCATION_OFFSET
> _SC_KERNEL_HZ
> 
> or somethings like that comes to mind.

Nah. HZ might be static here but we'll have more dynamic parameters so the 
sysconf API is rather inflexible there.

I was thinking of something that fits into existing perf API schemes, to keep 
it simple and self-sufficient, and to allow for extensions/etc.

	Ingo

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Peter Zijlstra]

On Wed, 2009-12-30 at 17:37 +0800, Xiao Guangrong wrote:
> > I really dislike the name, event injection to me would be like a write()
> > interface where you provide the actual event data to be stuffed in the
> > output stream.
> > 
> 
> Yes, it like write and it writes something form kernel to perf.
> And, i think this name is suitable for it's doing that injects an
> 'artificial' event, it's well if you have other name for it :-)

No, what I means is that you cannot actually inject an arbitrary event.
Sure it injects something, but that's pretty limited.

> > This just seems like a very weird way of getting data out. A kind of
> > like sysconf() but done very strange.
> > 
> 
> It's since some parameter is only used by perf, suce as HZ in this patch and
> 'relocation offset' in my other patchset, it also well if has better way to
> do it :-)

The thing is, this proposed interface is very much tied to perf and
makes it basically impossible for !perf to use. Whereas I can imagine
esp. the relocation offset to be interesting for other things. Basically
everything needing to resolve a kernel symbol.

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Peter Zijlstra]

On Wed, 2009-12-30 at 10:36 +0100, Peter Zijlstra wrote:
> On Wed, 2009-12-30 at 10:28 +0100, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Tue, 2009-12-29 at 13:21 +0800, Xiao Guangrong wrote:
> > > > 'inject' event is a very useful feature and it's suggested by Ingo
> > > > [ See http://lkml.org/lkml/2009/12/28/31 ]
> > > 
> > > I really dislike the name, event injection to me would be like a write() 
> > > interface where you provide the actual event data to be stuffed in the 
> > > output stream.
> > > 
> > > This just seems like a very weird way of getting data out. A kind of like 
> > > sysconf() but done very strange.
> > 
> > What kind of API would you suggest?
> 
> sysconf() seems ideal for getting single, mostly constant variables out
> of the kernel, we already have non POSIX (read Linux specific) names in
> there.
> 
> _SC_KERNEL_RELOCATION_OFFSET
> _SC_KERNEL_HZ
> 
> or somethings like that comes to mind.

OK so there is no sysconf() syscall and its all implemented in glibc,
which is utter suckage.. will have to come up with something saner then.

Re: [PATCH v3 1/5] perf_event: introduce 'inject' event and get HZ

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> OK so there is no sysconf() syscall and its all implemented in glibc, which 
> is utter suckage.. will have to come up with something saner then.

I think integrating it into the perf stream of events would be the most 
desirable approach - tooling could make use of it easily.

For data record (and hierarchy) description /debug/tracing/events/ would be 
useful.

We dont want to actually 'activate' them in an 'event' fashion - but we could 
use event IDs and the record format and the transport to describe and recover 
the values.

For transport we could use the mmap ring-buffer and it would also be nice to 
add (or resurrect) some 'quick & easy' read()/write() based transport. It a 
bit like a value read-out from a counter - just here it's not a regular 
counter but some sort of kernel-internal value that we want to provide.

Hm?

	Ingo