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: Arnaldo Carvalho de Melo on 17 Jun 2010 10:30 Em Thu, Jun 17, 2010 at 03:43:57PM +0200, Borislav Petkov escreveu: > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > Date: Mon, Jun 14, 2010 at 10:02:01PM -0300 > > > 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. I'm not that familiar with the trace bits in perf, but I'd say pick what is needed for your tool and stash it into files in a tools/lib/trace/ directory, in a way that can be used by both perf and your tools. I.e. no need to move files as-is, you can reorganize things to make it useful for both perf and your tool. > 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? If we do it on a as-needed basis, as I suggested, we go eroding the current perf hodgepodge of potentially generic stuff. > 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... - 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 11:30 From: Arnaldo Carvalho de Melo <acme(a)infradead.org> Date: Thu, Jun 17, 2010 at 11:25:46AM -0300 > Em Thu, Jun 17, 2010 at 03:43:57PM +0200, Borislav Petkov escreveu: > > From: Arnaldo Carvalho de Melo <acme(a)infradead.org> > > Date: Mon, Jun 14, 2010 at 10:02:01PM -0300 > > > > 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. > > I'm not that familiar with the trace bits in perf, but I'd say pick what > is needed for your tool and stash it into files in a tools/lib/trace/ > directory, in a way that can be used by both perf and your tools. > > I.e. no need to move files as-is, you can reorganize things to make it > useful for both perf and your tool. Right, this is the idea. However, all those header includes pull in other stuff. For example, if I want to use parse_events(), it pulls in parse-options.* which pulls in header.h, symbol.h etc. What I ended up doing is have tools/lib/perf/ /trace/ /include/ /lk/ for all the different types of facilities. So lk contains the generic perf/util/ stuff, include contains all the linux and asm headers like bitops.h, hash.h, kernel.h etc, perf contains parse-events.* because it deals with perf stuff and so on. How's that? > > 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? > > If we do it on a as-needed basis, as I suggested, we go eroding the > current perf hodgepodge of potentially generic stuff. I think splitting it in kinda "subsystems" helps keep the modularity. Opinions, comments? -- 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/
From: Steven Rostedt on 17 Jun 2010 12:30 On Thu, 2010-06-17 at 15:43 +0200, Borislav Petkov wrote: > > 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. Note, I have a separate generic library in trace-cmd that has the parsing of trace events as its own library now. This is the code that started trace-event-parse.c. It has evolved quite a bit since then. You can get the code from: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git The files are parse-events.c and parse-events.h. As well as some filtering code: parse-filter.c. It creates a libparsevent library. I've been meaning to update the perf stuff with it, but just have not had the time. Seems that what you are doing might be a good fit for it. -- Steve -- 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 13:40
From: Steven Rostedt <rostedt(a)goodmis.org> Date: Thu, Jun 17, 2010 at 12:19:57PM -0400 > On Thu, 2010-06-17 at 15:43 +0200, Borislav Petkov wrote: > > > > 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. > > Note, I have a separate generic library in trace-cmd that has the > parsing of trace events as its own library now. > > This is the code that started trace-event-parse.c. > > It has evolved quite a bit since then. You can get the code from: > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git > > The files are parse-events.c and parse-events.h. As well as some > filtering code: parse-filter.c. > > It creates a libparsevent library. > > I've been meaning to update the perf stuff with it, but just have not > had the time. Seems that what you are doing might be a good fit for it. I see, well, I could take it and merge it into tools/trace-cmd or something and then we all could gradually weed out common code. But I'm open to other suggestions as well. I mean, it is only natural if we merry perf and ftrace in kernel space to do the same in userspace, right :) -- 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/ |