perf: Add persistent events
in [Kernel]
|
Prev: [PATCH 2/2] x86, mce: Make MCE tracepoint persistent event
Next: [2.6.34-git8][regression] massive polling problems with udevd and other processes
From: Borislav Petkov on 14 Jun 2010 17:30 From: Arnaldo Carvalho de Melo <acme(a)infradead.org> Date: Mon, Jun 14, 2010 at 06:01:16PM -0300 > > Right, so I started playing with this, added a global Makefile to tools/ > > and from there we descend into lib/ and perf/ in that order to prepare > > all the modules for the perflib. I've played with the include paths so > > that you can have #include <util/util.h> for all that generic library > > stuff. > > > > The patch below carves out the debugfs helpers along with some generic > > headers, please take a look and let me know if this is an agreeable > > direction I'm going. Yeah, it is big, I think vger won't be able to > > swallow it but this is only moving files around so... > > One thing I thought was that perhaps reusing Kbuild would be a good > idea, something like: > > cd tools/ > make menuconfig > > And use all the Kbuild machinery to select needed features, etc. > > What do you think? Why not, however, do we need it at this point? I mean, you simply do make -j; make install in tools/perf/ and all is good. It even tells you if some libraries are missing. I simply don't see such a large amount of options to justify a configurator but maybe there are usecases where Kconfig would make sense, hmmm? > It can be a follow up to what you're doing, that is needed anyway, some > questions below: > > > Thanks. > > > > -- > > >From 0f391f0acf39d3b2e85145dce389cbf425cb7cdd Mon Sep 17 00:00:00 2001 > > From: Borislav Petkov <borislav.petkov(a)amd.com> > > Date: Mon, 14 Jun 2010 21:14:15 +0200 > > Subject: [PATCH] perf: rewire generic library stuff > > > > --- > > tools/Makefile | 74 +++++ > > tools/lib/Makefile | 41 +++ > > tools/lib/util/cache.h | 86 ++++++ > > tools/lib/util/debugfs.c | 252 +++++++++++++++++ > > tools/lib/util/debugfs.h | 31 +++ > > tools/lib/util/strbuf.c | 133 +++++++++ > > tools/lib/util/strbuf.h | 92 +++++++ > > tools/lib/util/types.h | 17 ++ > > tools/lib/util/util.h | 282 ++++++++++++++++++++ > > Will we continue using "util" here? What other name could we pick? Nah, > probably for the ones you moved we can continue using it, the symbols > part I plan to move to tools/lib/symbol/. Yeah, names are kinda arbitrary. Keeping "util" meant as little changes as possible but it would make more sense to simply have all different library modules under "tools/lib/<module>.(c|h)" Will do so in the next version. > > tools/perf/Makefile | 64 +---- > > tools/perf/bench/bench.h | 2 + > > tools/perf/bench/mem-memcpy.c | 2 +- > > tools/perf/bench/sched-messaging.c | 2 +- > > tools/perf/bench/sched-pipe.c | 2 +- > > tools/perf/builtin-bench.c | 2 +- > > tools/perf/builtin.h | 4 +- > > > -#include "types.h" > > +#include <util/types.h> > > I thought about suggesting using -I to reduce patch size, but then it is > using "" :-\ Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all library includes would be like: #include <util.h> however, this does not differentiate perflib (let's call it that for how :) from libc headers. Do we want a "perf" or "kernel" or "perflib" or whatever prefix here - it might make sense later when this thing grows to differentiate between the namespaces...? > So I'll do some testing here and merge this for .36 unless somebody has > other issues with this, Ingo? Frédéric? Can you please wait a bit with the merging, I'd like to write the whole rasd daemon stuff before we merge that and have the generic lib carve-out in one patchset? Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 14 Jun 2010 21:10 Em Mon, Jun 14, 2010 at 11:24:26PM +0200, Borislav Petkov escreveu: > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > > One thing I thought was that perhaps reusing Kbuild would be a good > > idea, something like: > > > > cd tools/ > > make menuconfig > > > > And use all the Kbuild machinery to select needed features, etc. > > > > What do you think? > > Why not, however, do we need it at this point? I mean, you simply do > > make -j; make install > > in tools/perf/ and all is good. It even tells you if some libraries are > missing. I simply don't see such a large amount of options to justify > a configurator but maybe there are usecases where Kconfig would make > sense, hmmm? Yeah, I mean longer term, as we get libraries separated, more benchmarks, tools, etc. > > It can be a follow up to what you're doing, that is needed anyway, some > > questions below: > > > tools/lib/util/util.h | 282 ++++++++++++++++++++ > > > > Will we continue using "util" here? What other name could we pick? Nah, > > probably for the ones you moved we can continue using it, the symbols > > part I plan to move to tools/lib/symbol/. > Yeah, names are kinda arbitrary. Keeping "util" meant as little changes as > possible but it would make more sense to simply have all different library > modules under "tools/lib/<module>.(c|h)" Will do so in the next version. Ok > > > tools/perf/builtin-bench.c | 2 +- > > > tools/perf/builtin.h | 4 +- > > > > > -#include "types.h" > > > +#include <util/types.h> > > > > I thought about suggesting using -I to reduce patch size, but then it is > > using "" :-\ > > Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all > library includes would be like: > > #include <util.h> > > however, this does not differentiate perflib (let's call it that for how > :) from libc headers. Do we want a "perf" or "kernel" or "perflib" or > whatever prefix here - it might make sense later when this thing grows > to differentiate between the namespaces...? Agreed, but the last name this thing will have will be 'perf'something :-) One of the goals at least I have with pursuing this path is to separate out everything that is not strictly 'perf' into things that can be reused by other tools, like yours. > > So I'll do some testing here and merge this for .36 unless somebody has > > other issues with this, Ingo? Fr�d�ric? > Can you please wait a bit with the merging, I'd like to write the > whole rasd daemon stuff before we merge that and have the generic lib > carve-out in one patchset? Ok with me, I'll see if I manage to do the symbols part tho, as it is kinda self contained and I already toyed with writing a test program that uses the subset of tools/perf/util/ that deals with symbols. Part of that experiment is in tools/perf/builtin-test.c, parts are exemplified by this Makefile: [acme(a)doppio linux-2.6-tip]$ cat tools/perf/util/examples/symbol/Makefile ppio linux-2.6-tip]$ l tools/perf/util/examples/symbol/Makefile -rw-rw-r-- 1 acme acme 693 2010-03-27 11:14 tools/perf/util/examples/symbol/Makefile CFLAGS = -Wall -I../../include -I../.. -std=gnu99 -DNO_DEMANGLE -g LDFLAGS = -lelf ifeq ("$(origin O)", "command line") OUTPUT := $(O)/ endif LIBSYM_OBJS = $(OUTPUT)map.o $(OUTPUT)rbtree.o $(OUTPUT)symbol.o $(OUTPUT)strlist.o $(OUTPUT)eprintf.o all: $(OUTPUT)dsym $(OUTPUT)ksym $(OUTPUT)dsym: $(OUTPUT)dsym.o $(LIBSYM_OBJS) gcc -o $@ $(LDFLAGS) $@.o $(LIBSYM_OBJS) $(OUTPUT)ksym: $(OUTPUT)ksym.o $(LIBSYM_OBJS) gcc -o $@ $(LDFLAGS) $@.o $(LIBSYM_OBJS) $(OUTPUT)rbtree.o: ../../../../../lib/rbtree.c gcc -o $@ -c $(CFLAGS) $< $(OUTPUT)%.o: ../../%.c gcc -o $@ -c $(CFLAGS) $< $(OUTPUT)%.o: %.c gcc -o $@ -c $(CFLAGS) $< clean: rm -f $(LIBSYM_OBJS) $(OUTPUT)?sym.o $(OUTPUT)?sym [acme(a)doppio linux-2.6-tip]$ [acme(a)doppio linux-2.6-tip]$ cd tools/perf/util/examples/symbol/ [acme(a)doppio symbol]$ l build/ total 104 drwxrwxr-x 2 acme acme 4096 2010-06-14 21:55 ./ drwxrwxr-x 3 acme acme 4096 2010-03-28 13:52 ../ -rwxrwxr-x 1 acme acme 47040 2010-06-14 21:55 dsym* -rwxrwxr-x 1 acme acme 47200 2010-06-14 21:55 ksym* [acme(a)doppio symbol]$ ldd build/dsym linux-vdso.so.1 => (0x00007fffe6cf2000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003404c00000) libc.so.6 => /lib64/libc.so.6 (0x0000003715a00000) /lib64/ld-linux-x86-64.so.2 (0x0000003715600000) [acme(a)doppio symbol]$ [acme(a)doppio symbol]$ build/dsym usage: dso DSO_NAME SYMBOL_NAME|0xADDR [acme(a)doppio symbol]$ build/dsym /lib/libc-2.10.2.so malloc malloc: 0x749c0-0x74bee [acme(a)doppio symbol]$ build/dsym /lib/libc-2.10.2.so 0x749ee __GI___libc_malloc: 0x749c0-0x74bee [acme(a)doppio symbol]$ build/dsym /lib/libc-2.10.2.so __GI___libc_malloc __GI___libc_malloc: 0x749c0-0x74bee :-) - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 15 Jun 2010 06:30 From: Arnaldo Carvalho de Melo <acme(a)infradead.org> Date: Mon, Jun 14, 2010 at 09:02:01PM -0400 > Em Mon, Jun 14, 2010 at 11:24:26PM +0200, Borislav Petkov escreveu: > > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > > > One thing I thought was that perhaps reusing Kbuild would be a good > > > idea, something like: > > > > > > cd tools/ > > > make menuconfig > > > > > > And use all the Kbuild machinery to select needed features, etc. > > > > > > What do you think? > > > > Why not, however, do we need it at this point? I mean, you simply do > > > > make -j; make install > > > > in tools/perf/ and all is good. It even tells you if some libraries are > > missing. I simply don't see such a large amount of options to justify > > a configurator but maybe there are usecases where Kconfig would make > > sense, hmmm? > > Yeah, I mean longer term, as we get libraries separated, more benchmarks, > tools, etc. Sure, this is generally a good idea. > > > > It can be a follow up to what you're doing, that is needed anyway, some > > > questions below: > > > > > tools/lib/util/util.h | 282 ++++++++++++++++++++ > > > > > > Will we continue using "util" here? What other name could we pick? Nah, > > > probably for the ones you moved we can continue using it, the symbols > > > part I plan to move to tools/lib/symbol/. > > > Yeah, names are kinda arbitrary. Keeping "util" meant as little changes as > > possible but it would make more sense to simply have all different library > > modules under "tools/lib/<module>.(c|h)" Will do so in the next version. > > Ok > > > > > tools/perf/builtin-bench.c | 2 +- > > > > tools/perf/builtin.h | 4 +- > > > > > > > -#include "types.h" > > > > +#include <util/types.h> > > > > > > I thought about suggesting using -I to reduce patch size, but then it is > > > using "" :-\ > > > > Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all > > library includes would be like: > > > > #include <util.h> > > > > however, this does not differentiate perflib (let's call it that for how > > :) from libc headers. Do we want a "perf" or "kernel" or "perflib" or > > whatever prefix here - it might make sense later when this thing grows > > to differentiate between the namespaces...? > > Agreed, but the last name this thing will have will be 'perf'something :-) > > One of the goals at least I have with pursuing this path is to separate > out everything that is not strictly 'perf' into things that can be reused > by other tools, like yours. Ok, since I'm a big fan of unambiguous short names, let's call it "lk" for "linux kernel" and have this namespace for all generic headers. So when you include those, you have something like #include <lk/util.h> How does that sound? > > > So I'll do some testing here and merge this for .36 unless somebody has > > > other issues with this, Ingo? Fr�d�ric? > > > Can you please wait a bit with the merging, I'd like to write the > > whole rasd daemon stuff before we merge that and have the generic lib > > carve-out in one patchset? > > Ok with me, I'll see if I manage to do the symbols part tho, as it is > kinda self contained and I already toyed with writing a test program > that uses the subset of tools/perf/util/ that deals with symbols. Neat, let's sync when I got my stuff ready so that we merge it together and fixup any paths fallout that might happen. Thanks. -- Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 15 Jun 2010 09:30 Em Tue, Jun 15, 2010 at 12:22:59PM +0200, Borislav Petkov escreveu: > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > Date: Mon, Jun 14, 2010 at 09:02:01PM -0400 > > > Em Mon, Jun 14, 2010 at 11:24:26PM +0200, Borislav Petkov escreveu: > > > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > > > > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > > > > Will we continue using "util" here? What other name could we pick? Nah, > > > > probably for the ones you moved we can continue using it, the symbols > > > > part I plan to move to tools/lib/symbol/. > > > Em Mon, Jun 14, 2010 at 11:24:26PM +0200, Borislav Petkov escreveu: > > > Yeah, names are kinda arbitrary. Keeping "util" meant as little changes as > > > possible but it would make more sense to simply have all different library > > > modules under "tools/lib/<module>.(c|h)" Will do so in the next version. > > > > Ok > > > > > > > tools/perf/builtin-bench.c | 2 +- > > > > > tools/perf/builtin.h | 4 +- > > > > > > > > > -#include "types.h" > > > > > +#include <util/types.h> > > > > > > > > I thought about suggesting using -I to reduce patch size, but then it is > > > > using "" :-\ > > > > > > Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all > > > library includes would be like: > > > > > > #include <util.h> > > > > > > however, this does not differentiate perflib (let's call it that for how > > > :) from libc headers. Do we want a "perf" or "kernel" or "perflib" or > > > whatever prefix here - it might make sense later when this thing grows > > > to differentiate between the namespaces...? > > > > Agreed, but the last name this thing will have will be 'perf'something :-) > > > > One of the goals at least I have with pursuing this path is to separate > > out everything that is not strictly 'perf' into things that can be reused > > by other tools, like yours. > > Ok, since I'm a big fan of unambiguous short names, let's call it "lk" > for "linux kernel" and have this namespace for all generic headers. So > when you include those, you have something like > > #include <lk/util.h> > > How does that sound? As this code originated on the Linux kernel, should be OK and probably unused. Peter, ideas? - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 17 Jun 2010 09:50
From: Arnaldo Carvalho de Melo <acme(a)infradead.org> Date: Mon, Jun 14, 2010 at 10:02:01PM -0300 > > > I thought about suggesting using -I to reduce patch size, but then it is > > > using "" :-\ > > > > Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all > > library includes would be like: > > > > #include <util.h> > > > > however, this does not differentiate perflib (let's call it that for how > > :) from libc headers. Do we want a "perf" or "kernel" or "perflib" or > > whatever prefix here - it might make sense later when this thing grows > > to differentiate between the namespaces...? > > Agreed, but the last name this thing will have will be 'perf'something :-) > > One of the goals at least I have with pursuing this path is to separate > out everything that is not strictly 'perf' into things that can be reused > by other tools, like yours. I'm still splitting perf/util into a more or less generic lib. Now, I want to reuse as much code as possible and am parsing the "mce:mce_record" tracepoint using parse_events(). However, this means that I have to push the not-so-generic perf bits like util/parse-events.c into the lib. Which, in turn, pulls in util/trace-event* etc. What is your preference, do we want to export all perf/util stuff for other tools to use or rather link other tools together with compilation modules from perf/util in case those other tools need them? I'm leaning towards the first one and am thinking "maximize code reuse" but I'm not completely sure, there might be reasons against it... Hmm...? -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Gemeinde Aschheim, Landkreis M�nchen Registergericht Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |