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.
Signed-off-by: Stephane Eranian <[email protected]>
--
Hi Stephane,
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 (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 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.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Stephen,
On Mon, Jul 28, 2008 at 8:47 AM, Stephen Rothwell <[email protected]> wrote:
>
> 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:
>
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.
> 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.
>
> 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.
> 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
On Mon, Jul 28, 2008 at 11:20 PM, stephane eranian
<[email protected]> wrote:
>> 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,
On Wed, 30 Jul 2008 16:59:34 -0700 "stephane eranian" <[email protected]> wrote:
>
> On Mon, Jul 28, 2008 at 11:20 PM, stephane eranian
> <[email protected]> wrote:
> >> 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.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Stephen
On Wed, Jul 30, 2008 at 5:21 PM, Stephen Rothwell <[email protected]> wrote:
> Hi Stephane,
>
> On Wed, 30 Jul 2008 16:59:34 -0700 "stephane eranian" <[email protected]> wrote:
>>
>> On Mon, Jul 28, 2008 at 11:20 PM, stephane eranian
>> <[email protected]> wrote:
>> >> 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!
> 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.
On Wed, 30 Jul 2008 17:26:10 -0700 "stephane eranian" <[email protected]> wrote:
>
> > 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.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/