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: Peter Zijlstra on 28 May 2010 11:20 On Fri, 2010-05-28 at 16:33 +0200, Ingo Molnar wrote: > > 2) get these things a buffer, perf_events as created don't actually > > have an output buffer, normally that is created at mmap() time, but > > since you cannot mmap() a kernel side event, it doesn't get to have > > a buffer. This could be done by extracting perf_mmap_data_alloc() > > into a sensible interface. > > #2 could be a new syscall: sys_create_ring_buffer or so? No, they need a buffer in-kernel, syscalls aren't the ideal tool for that :-) I've got patches refactoring the whole buffer stuff to make it more a self-contained entity. -- 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 28 May 2010 12:00 From: Peter Zijlstra <peterz(a)infradead.org> Date: Fri, May 28, 2010 at 05:17:40PM +0200 > On Fri, 2010-05-28 at 16:33 +0200, Ingo Molnar wrote: > > > > 2) get these things a buffer, perf_events as created don't actually > > > have an output buffer, normally that is created at mmap() time, but > > > since you cannot mmap() a kernel side event, it doesn't get to have > > > a buffer. This could be done by extracting perf_mmap_data_alloc() > > > into a sensible interface. > > > > #2 could be a new syscall: sys_create_ring_buffer or so? > > No, they need a buffer in-kernel, syscalls aren't the ideal tool for > that :-) Yeah, I need a per-cpu buffer ready at event registration/enable time, maybe even have perf_event_create_kernel_counter() take care of that buffer allocation with a flag or similar prior to enabling the event... > I've got patches refactoring the whole buffer stuff to make it more a > self-contained entity. Can I see those when you're done so that I can base my stuff on top? 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 3 Jun 2010 13:40 Em Thu, Jun 03, 2010 at 03:43:01PM +0200, Borislav Petkov escreveu: > From: Peter Zijlstra <peterz(a)infradead.org> > Date: Fri, May 28, 2010 at 08:07:10PM +0200 > > to allocate and attach a buffer to your event (do so for each cpu's MCE > > event). > > > > After that we still need a way to expose all that to userspace, but at > > least the events will be complete and able to record bits ;-) > > Yep, so far so good, the kernel side is almost done - this was the > easy part :). So recently I started looking into how the userspace > part could be done most efficiently so that, initially, the RAS daemon > doesn't suck in all of tools/perf when building and depend unnecessary > on libelf etc, and, at the same time, doesn't duplicate functionality > like util/debugfs, get_debugfs_mntpt(), parse_events() maybe later etc. > > So, the best way to do this, IMHO, is if I start carving out common and > generic functionality into tools/lib/ or tools/util/ or similar so that > perf and ras can share those. And maybe later even other tools. This > could be where we host all the kernel headers stuff which are good for > userspace, i.e. those which are in tools/perf/util/include/linux/ > > Opinions, comments? Right, that has to be done, I have sample code I want to put in samples/ to show how to use the symbol libraries in tools/perf/util/, will take a stab at moving things for tools/lib/. We'll need a top level Makefile, I guess, so that when asking to build tools/perf, it notices that it has to build tools/lib/, etc. Probably we'll need tools/lib/symbols/, tools/lib/trace/parser/ things like that, I'll start with the symbols part, using a samples/ file I already wrote. - 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 3 Jun 2010 17:50 From: Arnaldo Carvalho de Melo <acme(a)infradead.org> Date: Thu, Jun 03, 2010 at 02:32:42PM -0300 > Em Thu, Jun 03, 2010 at 03:43:01PM +0200, Borislav Petkov escreveu: > > From: Peter Zijlstra <peterz(a)infradead.org> > > Date: Fri, May 28, 2010 at 08:07:10PM +0200 > > > to allocate and attach a buffer to your event (do so for each cpu's MCE > > > event). > > > > > > After that we still need a way to expose all that to userspace, but at > > > least the events will be complete and able to record bits ;-) > > > > Yep, so far so good, the kernel side is almost done - this was the > > easy part :). So recently I started looking into how the userspace > > part could be done most efficiently so that, initially, the RAS daemon > > doesn't suck in all of tools/perf when building and depend unnecessary > > on libelf etc, and, at the same time, doesn't duplicate functionality > > like util/debugfs, get_debugfs_mntpt(), parse_events() maybe later etc. > > > > So, the best way to do this, IMHO, is if I start carving out common and > > generic functionality into tools/lib/ or tools/util/ or similar so that > > perf and ras can share those. And maybe later even other tools. This > > could be where we host all the kernel headers stuff which are good for > > userspace, i.e. those which are in tools/perf/util/include/linux/ > > > > Opinions, comments? > > Right, that has to be done, I have sample code I want to put in samples/ > to show how to use the symbol libraries in tools/perf/util/, will take a > stab at moving things for tools/lib/. Cool. > We'll need a top level Makefile, I guess, so that when asking to build > tools/perf, it notices that it has to build tools/lib/, etc. Yep. > Probably we'll need tools/lib/symbols/, tools/lib/trace/parser/ things > like that, I'll start with the symbols part, using a samples/ file I > already wrote. Nice, let me know when you have something ready so that we don't duplicate work. Also, I could give it a test run or two and all. 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 17:10
Em Mon, Jun 14, 2010 at 09:25:14PM +0200, Borislav Petkov escreveu: > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > Date: Thu, Jun 03, 2010 at 02:32:42PM -0300 > > > Right, that has to be done, I have sample code I want to put in samples/ > > to show how to use the symbol libraries in tools/perf/util/, will take a > > stab at moving things for tools/lib/. > > > > We'll need a top level Makefile, I guess, so that when asking to build > > tools/perf, it notices that it has to build tools/lib/, etc. > > > > Probably we'll need tools/lib/symbols/, tools/lib/trace/parser/ things > > like that, I'll start with the symbols part, using a samples/ file I > > already wrote. > > 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? 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/. > 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 "" :-\ So I'll do some testing here and merge this for .36 unless somebody has other issues with this, Ingo? Fr�d�ric? - 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/ |