perfmon2 minimal v3: introduction
cover perfmon2 minimal v3: introduction
The following patches implement a minimal perfmon2 subsystem which provides access to the hardware performance counters of modern processors. Performance counters are very useful resource to extract micro-architectural-level information such the number of caches misses, or the number of instructions executed. The list of events which can be monitored in highly specific to each processor implmentation.
This series supports ONLY per-thread counting of PMU events (no sampling) for AMD64 and Intel processors with support for architectural perfmon (Core Duo/Solo, Core 2) in both 32 and 64 bit modes.
This is version 3 of the series. It is against Stephen Rothwell linux-next GIT tree. Compared to the previous version, there were a few more cleanups in the Makefile structure suggested by Stephen. The series also merges more code between 32 and 64 bit x86.
Please review.
More information about the perfmon2 project can be found at:
http://perfmon2.sourceforge.net
To test this series, it is possible to use libpfm and pfmon, both available from the web site above.
Hi Stephane,
Quoted 3 lines · On Mon, 30 Jun 2008 06:13:26 -0700 (PDT) [email protected] wrote:
The following patches implement a minimal perfmon2 subsystem which provides access to the hardware performance counters of modern processors.
First up, I cannot speak to the actual function of the patches, but just to the mechanics of getting them into the kernel. One good thing is that with CONFIG_PERFMON turned off, it looks like the impact is very close to zero. Two obvious things that would help these being accepted are:
ordering - in the current incarnation, the patches produce places
where the kernel will not build. We like things to be ordered so that git bisection does not fail if at all possible - that means that an allmod/yesconfig should build after the application of each patch. Currently this is not so. It could be mode to do so trivially by delaying the "global" Kconfig/Makefile updates until later in the sequence. And you really should introduce the system calls *before* wiring them up.
quite a few of the macros (especially for the dummy (nonCONFIG_PERFMON) versions of functions) should be "static inline" functions unless they absolutely must be macros. Andrew Morton said it best - "write in C not C preprocessor".
I can see that this infrastructure could be very useful and I appreciate that it has been cut down for this initial merge. These patches (even as they are) compare favourably to some other new infrastructure that has been introduced.
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Stephen,
Quoted 11 lines · Stephen Rothwell
Quoted 3 lines · On Mon, 30 Jun 2008 06:13:26 -0700 (PDT) [email protected] wrote:
The following patches implement a minimal perfmon2 subsystem which provides access to the hardware performance counters of modern processors.
First up, I cannot speak to the actual function of the patches, but just to the mechanics of getting them into the kernel. One good thing is that with
CONFIG_PERFMONturned off, it looks like the impact is very close to zero. Two obvious things that would help these being accepted are:
Yes, when CONFIG_PERFMON is off, there should be no penalty at all. The hooks are removed via empty inline functions. The extra field in task_struct is removed. In x86-specific code, the low-level interrupt code is removed. The TIF flags are unused, thus no impact on context switch because the thread_info cacheline is checked regardless of perfmon2.
Quoted 8 lines
ordering - in the current incarnation, the patches produce places
where the kernel will not build. We like things to be ordered so that git bisection does not fail if at all possible - that means that an allmod/yesconfig should build after the application of each patch. Currently this is not so. It could be mode to do so trivially by delaying the "global" Kconfig/Makefile updates until later in the sequence. And you really should introduce the system calls *before* wiring them up.
I will restructure the patch series so it can be built at any one level of of th patch stack.
Quoted 6 lines
quite a few of the macros (especially for the dummy (non
CONFIG_PERFMON) versions of functions) should be "static inline" functions unless they absolutely must be macros. Andrew Morton said it best - "write in C not C preprocessor".
I will fix that as well.
Quoted 4 lines
I can see that this infrastructure could be very useful and I appreciate that it has been cut down for this initial merge. These patches (even as they are) compare favourably to some other new infrastructure that has been introduced.
I think I can break it down a bit more especially for x86_64.
As discussed with people on LKML and with Andi Kleen last week at OLS, I will see what can be done with the syscalls to make them a bit more extensible.
Thanks.
Stephen
Quoted 5 lines · stephane eranian
Quoted 5 lines
quite a few of the macros (especially for the dummy (non
CONFIG_PERFMON) versions of functions) should be "static inline" functions unless they absolutely must be macros. Andrew Morton said it best - "write in C not C preprocessor".
Do you also have a problem with the debug printk statements using macros?
Hi Stephane,
Quoted 9 lines · On Wed, 30 Jul 2008 16:59:34 -0700 "stephane eranian" <[email protected]>…
Quoted 5 lines · stephane eranian
Quoted 5 lines
quite a few of the macros (especially for the dummy (non
CONFIG_PERFMON) versions of functions) should be "static inline" functions unless they absolutely must be macros. Andrew Morton said it best - "write in C not C preprocessor".Do you also have a problem with the debug printk statements using macros?
Not really, they would be a pain to write as C code.
The advantage of using C code for the dummy versions of things is that we still get type checking and we eliminate "unused variable" warnings for parameters of the functions.
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Stephen
Quoted 6 lines · Stephen Rothwell
Hi Stephane,
Quoted 3 lines · On Wed, 30 Jul 2008 16:59:34 -0700 "stephane eranian" <[email protected]>…
On Mon, Jul 28, 2008 at 11:20 PM, stephane eranian <[email protected]> wrote:
Quoted 9 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
quite a few of the macros (especially for the dummy (non
CONFIG_PERFMON) versions of functions) should be "static inline" functions unless they absolutely must be macros. Andrew Morton said it best - "write in C not C preprocessor".Do you also have a problem with the debug printk statements using macros?
Not really, they would be a pain to write as C code.
That's what I am thinking as well!
Quoted 4 lines
The advantage of using C code for the dummy versions of things is that we still get type checking and we eliminate "unused variable" warnings for parameters of the functions.
Will do the dummy functions as inline then.
Quoted 6 lines · On Wed, 30 Jul 2008 17:26:10 -0700 "stephane eranian" <[email protected]>…
Quoted 5 lines
The advantage of using C code for the dummy versions of things is that we still get type checking and we eliminate "unused variable" warnings for parameters of the functions.
Will do the dummy functions as inline then.
Thanks.
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/