[PATCH 03/21] perf_events: Add a helper to search for an event in a context

[PATCH 03/21] perf_events: Add a helper to search for an event in a context

[Borislav Petkov]

From: Borislav Petkov <borislav.petkov@amd.com>

This is a straignt-forward helper to look for, e.g. already allocated
and enabled events (think persistent events here).

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 kernel/perf_event.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 40478af..168764b 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -307,6 +307,27 @@ list_add_event(struct perf_event *event, struct perf_event_context *ctx)
 		ctx->nr_stat++;
 }
 
+/*
+ * Find an event in a context.
+ * Must be called with ctx->mutex and ctx->lock held.
+ */
+static struct perf_event *find_event_in_context(struct perf_event_attr *attr,
+						struct perf_event_context *ctx)
+{
+	struct perf_event *event;
+
+	rcu_read_lock();
+	list_for_each_entry_rcu(event, &ctx->event_list, event_entry) {
+		if (event->attr.config == attr->config) {
+			rcu_read_unlock();
+			return event;
+		}
+	}
+	rcu_read_unlock();
+
+	return NULL;
+}
+
 static void perf_group_attach(struct perf_event *event)
 {
 	struct perf_event *group_leader = event->group_leader;
-- 
1.7.1

Re: [PATCH 05/21] perf: rewire generic library stuff, p1

[Borislav Petkov]

From: Arnaldo Carvalho de Melo <acme@infradead.org>
Date: Thu, Jul 01, 2010 at 12:10:54PM -0400

Hi Arnaldo,

> Em Thu, Jul 01, 2010 at 12:47:37PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Jul 01, 2010 at 03:49:19PM +0200, Borislav Petkov escreveu:
> > > From: Borislav Petkov <borislav.petkov@amd.com>
> > > 
> > > Carve out generic library stuff into tools/lib/lk/ and rewire it with
> > > perf. Add a top-level Makefile which selects between targets depending
> > > on the tool we want to build. Also, add a Makefile.lib for common
> > > facilities used by all the Makefiles.
> > 
> > Testing this now, thanks,
> 
> Needs the patch below for "make O=~/build/perf tools" to continue
> working. Needs some more polishing so as not to break the non O= case.
> 
> After lunch will investigate why my usual way to build the tools isn't working
> anymore, some missing -I probably:
> 
> [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf install
> make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
>     CC /home/acme/git/build/perf/builtin-record.o
> builtin-record.c:24:23: error: lk/cpumap.h: No such file or directory
> cc1: warnings being treated as errors
> builtin-record.c: In function ‘__cmd_record’:
> builtin-record.c:622: error: implicit declaration of function ‘read_cpu_map’
> builtin-record.c:632: error: ‘cpumap’ undeclared (first use in this function)
> builtin-record.c:632: error: (Each undeclared identifier is reported only once
> builtin-record.c:632: error: for each function it appears in.)
> make: *** [/home/acme/git/build/perf/builtin-record.o] Error 1
> make: Leaving directory `/home/acme/git/linux-2.6-tip/tools/perf'
> [acme@emilia linux-2.6-tip]$
> 
> diff --git a/tools/lib/Makefile b/tools/lib/Makefile
> index 48f8e21..814673e 100644
> --- a/tools/lib/Makefile
> +++ b/tools/lib/Makefile
> @@ -5,6 +5,9 @@ LIB_H =
>  LIB_OBJS =
>  
>  LIB_H += lk/cpumap.h
> +OUTPUT := $(OUTPUT)/lib/
> +
> +$(shell sh -c 'mkdir -p $(OUTPUT)/lk' 2> /dev/null)
>  
>  LIB_OBJS += $(OUTPUT)lk/bitmap.o
>  LIB_OBJS += $(OUTPUT)lk/cpumap.o

I'll fix that up, thanks for testing.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [PATCH 03/21] perf_events: Add a helper to search for an event in a context

[Borislav Petkov]

From: Frederic Weisbecker <fweisbec@gmail.com>
Date: Thu, Jul 01, 2010 at 12:14:50PM -0400

Hi Frederic,

> On Thu, Jul 01, 2010 at 06:12:45PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-01 at 18:11 +0200, Frederic Weisbecker wrote:
> > > I suspect we need another syscall that can list all the persistent events
> > > with a unique id and the attrs that follow.
> > > 
> > > So you get a unique id for all of them and you can create an fd on top
> > > of this id by using a PERF_FLAG_REQUEST_PERSISTENT and this id put in
> > > attr.config. 
> > 
> > Isn't that what filesystems were invented for?
> 
> 
> The problem is when you create a persistent event, you lose the fd.
> So you need to retrieve it somehow.

actually the idea is to decouple those from the fd alltogether and
provide specific file_operations in debugfs and such, as Peter
suggested. Which sounds much more sane to me especially since, at least
in the MCE case, all the entities that register into that event need to
see the same samples (and read the same buffers etc).

And let's try not to read too much into those persistent events - it may
just as well be that we need them only for MCEs and nothing else :)

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [PATCH 03/21] perf_events: Add a helper to search for an event in a context

[Frederic Weisbecker]

On Thu, Jul 01, 2010 at 06:24:24PM +0200, Borislav Petkov wrote:
> From: Frederic Weisbecker <fweisbec@gmail.com>
> Date: Thu, Jul 01, 2010 at 12:14:50PM -0400
> 
> Hi Frederic,
> 
> > On Thu, Jul 01, 2010 at 06:12:45PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-07-01 at 18:11 +0200, Frederic Weisbecker wrote:
> > > > I suspect we need another syscall that can list all the persistent events
> > > > with a unique id and the attrs that follow.
> > > > 
> > > > So you get a unique id for all of them and you can create an fd on top
> > > > of this id by using a PERF_FLAG_REQUEST_PERSISTENT and this id put in
> > > > attr.config. 
> > > 
> > > Isn't that what filesystems were invented for?
> > 
> > 
> > The problem is when you create a persistent event, you lose the fd.
> > So you need to retrieve it somehow.
> 
> actually the idea is to decouple those from the fd alltogether and
> provide specific file_operations in debugfs and such, as Peter
> suggested. Which sounds much more sane to me especially since, at least
> in the MCE case, all the entities that register into that event need to
> see the same samples (and read the same buffers etc).



Sure the idea of putting that in fs is better.

Note the idea of a new syscall was quite close: it would have listed
unique ids of the persistent events, but not fds, you'd have yet to create
those fds on top of the ids.



> 
> And let's try not to read too much into those persistent events - it may
> just as well be that we need them only for MCEs and nothing else :)


Not really. It would be useful for boot tracing, amongst various other things
like flight recorder tracing, etc...

Re: [PATCH 05/21] perf: rewire generic library stuff, p1

[Arnaldo Carvalho de Melo]

Em Thu, Jul 01, 2010 at 06:17:38PM +0200, Borislav Petkov escreveu:
> From: Arnaldo Carvalho de Melo <acme@infradead.org>
> Date: Thu, Jul 01, 2010 at 12:10:54PM -0400
> 
> Hi Arnaldo,
> 
> > Em Thu, Jul 01, 2010 at 12:47:37PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Jul 01, 2010 at 03:49:19PM +0200, Borislav Petkov escreveu:
> > > > From: Borislav Petkov <borislav.petkov@amd.com>
> > > > 
> > > > Carve out generic library stuff into tools/lib/lk/ and rewire it with
> > > > perf. Add a top-level Makefile which selects between targets depending
> > > > on the tool we want to build. Also, add a Makefile.lib for common
> > > > facilities used by all the Makefiles.
> > > 
> > > Testing this now, thanks,
> > 
> > Needs the patch below for "make O=~/build/perf tools" to continue
> > working. Needs some more polishing so as not to break the non O= case.
> > 
> > After lunch will investigate why my usual way to build the tools isn't working
> > anymore, some missing -I probably:
> > 
> > [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf install
> > make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
> >     CC /home/acme/git/build/perf/builtin-record.o
> > builtin-record.c:24:23: error: lk/cpumap.h: No such file or directory
> > cc1: warnings being treated as errors

The patch below fixes it.

But we have one other problem:

[acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/
make: Entering directory `/home/acme/git/linux-2.6-tip/tools'
make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/lib'
make[1]: `lklib.a' is up to date.
make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/lib'
make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
    GEN perf-archive
make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/perf'
make: Leaving directory `/home/acme/git/linux-2.6-tip/tools'
[acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf/
make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
    * new build flags or prefix
    CC /home/acme/git/build/perf/perf.o
    CC /home/acme/git/build/perf/builtin-annotate.o
    CC /home/acme/git/build/perf/builtin-bench.o

The logic that detects "new build flags or prefix" gets confused when we
alternate between tools/ and tools/perf/, checking that.

- Arnaldo

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 200fc13..72ccd17 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -268,7 +268,7 @@ endif
 # Those must not be GNU-specific; they are shared with perl/ which may
 # be built by a different compiler. (Note that this is an artifact now
 # but it still might be nice to keep that distinction.)
-BASIC_CFLAGS += -Iutil/include -Iarch/$(ARCH)/include
+BASIC_CFLAGS += -Iutil/include -Iarch/$(ARCH)/include -I../lib/
 BASIC_LDFLAGS =
 
 # Guard against environment variables

Re: [PATCH 05/21] perf: rewire generic library stuff, p1

[Borislav Petkov]

From: Arnaldo Carvalho de Melo <acme@infradead.org>
Date: Thu, Jul 01, 2010 at 01:14:49PM -0400

> > > Needs the patch below for "make O=~/build/perf tools" to continue
> > > working. Needs some more polishing so as not to break the non O= case.
> > > 
> > > After lunch will investigate why my usual way to build the tools isn't working
> > > anymore, some missing -I probably:
> > > 
> > > [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf install
> > > make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
> > >     CC /home/acme/git/build/perf/builtin-record.o
> > > builtin-record.c:24:23: error: lk/cpumap.h: No such file or directory
> > > cc1: warnings being treated as errors
> 
> The patch below fixes it.
> 
> But we have one other problem:
> 
> [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/
> make: Entering directory `/home/acme/git/linux-2.6-tip/tools'
> make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/lib'
> make[1]: `lklib.a' is up to date.
> make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/lib'
> make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
>     GEN perf-archive
> make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/perf'
> make: Leaving directory `/home/acme/git/linux-2.6-tip/tools'
> [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf/
> make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
>     * new build flags or prefix
>     CC /home/acme/git/build/perf/perf.o
>     CC /home/acme/git/build/perf/builtin-annotate.o
>     CC /home/acme/git/build/perf/builtin-bench.o
> 
> The logic that detects "new build flags or prefix" gets confused when we
> alternate between tools/ and tools/perf/, checking that.

This might need an up-to-date check for the lklib.a archive first and
not do "new build flags or prefix" if it is. Yeah, this is a different
library and the logic doesn't know about it.

> - Arnaldo
> 
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 200fc13..72ccd17 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -268,7 +268,7 @@ endif
>  # Those must not be GNU-specific; they are shared with perl/ which may
>  # be built by a different compiler. (Note that this is an artifact now
>  # but it still might be nice to keep that distinction.)
> -BASIC_CFLAGS += -Iutil/include -Iarch/$(ARCH)/include
> +BASIC_CFLAGS += -Iutil/include -Iarch/$(ARCH)/include -I../lib/
>  BASIC_LDFLAGS =

Right, the whole scheme with the include paths is kinda shaky. I have
the -I$(CURDIR)/lib BASIC_CFLAGS in the top Makefile for the case where
we're in tools/ but this doesn't help with the -C switch as you show
above.

Maybe we should add more logic later to make the include path guessing
more robust no matter from which directory you execute make instead of
polluting BASIC_CFLAGS with duplicated path entries ... Hmmm...

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [PATCH 05/21] perf: rewire generic library stuff, p1

[Arnaldo Carvalho de Melo]

Em Thu, Jul 01, 2010 at 10:14:18PM +0200, Borislav Petkov escreveu:
> From: Arnaldo Carvalho de Melo <acme@infradead.org>
> Date: Thu, Jul 01, 2010 at 01:14:49PM -0400
> > But we have one other problem:

> > [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/
> > make: Entering directory `/home/acme/git/linux-2.6-tip/tools'
> > make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/lib'
> > make[1]: `lklib.a' is up to date.
> > make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/lib'
> > make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
> >     GEN perf-archive
> > make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/perf'
> > make: Leaving directory `/home/acme/git/linux-2.6-tip/tools'
> > [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf/
> > make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
> >     * new build flags or prefix
> >     CC /home/acme/git/build/perf/perf.o
> >     CC /home/acme/git/build/perf/builtin-annotate.o
> > 
> > The logic that detects "new build flags or prefix" gets confused when we
> > alternate between tools/ and tools/perf/, checking that.
> 
> This might need an up-to-date check for the lklib.a archive first and
> not do "new build flags or prefix" if it is. Yeah, this is a different
> library and the logic doesn't know about it.

I got sidetracked, but this is what is in $(O)/PERF-CFLAGS for
make -C tools/

[acme@emilia linux-2.6-tip]$ cat ../build/perf/PERF-CFLAGS 
-ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Wformat-y2k -Wshadow -Winit-self -Wpacked -Wredundant-decls -Wstack-protector -Wstrict-aliasing=3 -Wswitch-default -Wswitch-enum -Wno-system-headers -Wundef -Wvolatile-register-var -Wwrite-strings -Wbad-function-cast -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wstrict-prototypes -Wdeclaration-after-statement  -fstack-protector-all -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/acme/git/linux-2.6-tip/tools/lib -I/home/acme/git/linux-2.6-tip/tools/perf -I/home/acme/git/linux-2.6-tip/tools/perf/util/include -Iutil/include -Iarch/x86/include -I../lib/ -I/home/acme/git/build/perf/ -DLIBELF_NO_MMAP -I/usr/include/elfutils -DDWARF_SUPPORT -I/usr/include/slang -DSHA1_HEADER='<openssl/sha.h>' : /home/acme/bin:libexec/perf-core:share/perf-core/templates:/home/acme
[acme@emilia linux-2.6-tip]$

And this is its contents if we use "make -C tools/perf/"

-ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2   -fstack-protector-all -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I../lib/ -I/home/acme/git/build/perf/ -DLIBELF_NO_MMAP -I/usr/include/elfutils -DDWARF_SUPPORT -I/usr/include/slang -DSHA1_HEADER='<openssl/sha.h>' : /home/acme/bin:libexec/perf-core:share/perf-core/templates:/home/acme

Its just a matter of making both match :-)

- Arnaldo

Re: [PATCH 05/21] perf: rewire generic library stuff, p1

[Borislav Petkov]

From: Arnaldo Carvalho de Melo <acme@infradead.org>
Date: Thu, Jul 01, 2010 at 05:13:31PM -0400

> Em Thu, Jul 01, 2010 at 10:14:18PM +0200, Borislav Petkov escreveu:
> > From: Arnaldo Carvalho de Melo <acme@infradead.org>
> > Date: Thu, Jul 01, 2010 at 01:14:49PM -0400
> > > But we have one other problem:
> 
> > > [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/
> > > make: Entering directory `/home/acme/git/linux-2.6-tip/tools'
> > > make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/lib'
> > > make[1]: `lklib.a' is up to date.
> > > make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/lib'
> > > make[1]: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
> > >     GEN perf-archive
> > > make[1]: Leaving directory `/home/acme/git/linux-2.6-tip/tools/perf'
> > > make: Leaving directory `/home/acme/git/linux-2.6-tip/tools'
> > > [acme@emilia linux-2.6-tip]$ make O=~/git/build/perf -C tools/perf/
> > > make: Entering directory `/home/acme/git/linux-2.6-tip/tools/perf'
> > >     * new build flags or prefix
> > >     CC /home/acme/git/build/perf/perf.o
> > >     CC /home/acme/git/build/perf/builtin-annotate.o
> > > 
> > > The logic that detects "new build flags or prefix" gets confused when we
> > > alternate between tools/ and tools/perf/, checking that.
> > 
> > This might need an up-to-date check for the lklib.a archive first and
> > not do "new build flags or prefix" if it is. Yeah, this is a different
> > library and the logic doesn't know about it.
> 
> I got sidetracked, but this is what is in $(O)/PERF-CFLAGS for
> make -C tools/
> 
> [acme@emilia linux-2.6-tip]$ cat ../build/perf/PERF-CFLAGS 
> -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Wformat-y2k -Wshadow -Winit-self -Wpacked -Wredundant-decls -Wstack-protector -Wstrict-aliasing=3 -Wswitch-default -Wswitch-enum -Wno-system-headers -Wundef -Wvolatile-register-var -Wwrite-strings -Wbad-function-cast -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wstrict-prototypes -Wdeclaration-after-statement  -fstack-protector-all -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/acme/git/linux-2.6-tip/tools/lib -I/home/acme/git/linux-2.6-tip/tools/perf -I/home/acme/git/linux-2.6-tip/tools/perf/util/include -Iutil/include -Iarch/x86/include -I../lib/ -I/home/acme/git/build/perf/ -DLIBELF_NO_MMAP -I/usr/include/elfutils -DDWARF_SUPPORT -I/usr/include/slang -DSHA1_HEADER='<openssl/sha.h>' : /home/acme/bin:libexec/perf-core:share/perf-core/templates:/home/acme
> [acme@emilia linux-2.6-tip]$
> 
> And this is its contents if we use "make -C tools/perf/"
> 
> -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2   -fstack-protector-all -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Iutil/include -Iarch/x86/include -I../lib/ -I/home/acme/git/build/perf/ -DLIBELF_NO_MMAP -I/usr/include/elfutils -DDWARF_SUPPORT -I/usr/include/slang -DSHA1_HEADER='<openssl/sha.h>' : /home/acme/bin:libexec/perf-core:share/perf-core/templates:/home/acme
> 
> Its just a matter of making both match :-)

Oh yeah, I see the difference. The second one is missing all the -Wxxx
settings and the BASIS_CFLAGS with all the include paths which get
computed in the top Makefile and exported to the Makefiles in the
subdirectories. Hmm, maybe we should reroute the "make -C tools/perf/"
invocation to go up one dir and execute the top-Makefile after all...

I'll look into it soon, I'm almost falling asleep now :)

Good night.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632