perfmon3: introduction

Hello,

This series of patches implements the perfmon interface which provides access to the hardware performance counters of modern processors. In particular, this version supports per-thread counting for all AMD64 processors, and recent Intel processors with architectural PMU (Core Duo, Core 2, Atom).

It does not supersede Oprofile in this first implementation. Oprofile and perfmon can be compiled in the same kernel, but only one can have an active session at a time.

This implementation takes into account the various comments received from previous reviews on LKML. This is a much simplified version compared to the fully featured version maintained as a separate GIT tree on kernel.org.

This new version, named perfmon3, uses only 5 system calls (instead of 12). Each call was carefully designed to allow for future extensions.

Full documentation is available in Documentation/perfmon.txt and is provided by one of the patches.

Once this basic set of perfmon functionalities is upstream, we will build on it and add other features such as support for sampling, event set multiplexing and multi-architecture.

I will be releasing updated versions of libpfm and pfmon which can work with this new API while continuing to work with the v2.x versions.

The patch series is against 2.6.27.

Please consider adding this patch series for 2.6.28.

Thanks to all the people who have contributed to this new release.

S.Eranian

From: [email protected]
Date: Fri, 17 Oct 2008 08:05:07 -0700 (PDT)

What about the folks who worked hard on sparc, powerpc, et al. perfmon support? Do they "just lose" for the moment? :-/

I'm really disappointed that I did all of the work to make pfmon, libpfm, and the kernel bits work with perfmon on sparc and that appears to be all for nothing as there is no update for those architectures in this new patch set. So likely I'll have to do it all over again.

I definitely do not support this reincarnation, this is the last thing I expected to happen.

Three weeks of my own work down the drain which I invested (during which I put my networking maintainership and other responsibilities to the side) in order to help champion this perfmon stuff in the first place?

Gee, thanks...

Dave,

I was told to start with something very simple and for the key architecture, i.e,, X86.
That's what I did.

This is only the first step. I am not satisfied with this either. I do care about all the other
architectures as well. I do put a significant effort into maintaining those in the current
perfmon2 and perfmon3 incarnations. That includes SPARC.

Since your first patch, I have made sure SPARC would always compile and have the same level of functionality as other architectures. Just checkout the 2.6.27 patch on SF.net
for perfmon v2 or the GIT tree for perfmon v3 (perfmon3 branch).

The key thing is to get this basic block into the kernel, then we can add all the
other architectures. I will not forget about Sparc, Power, MIPS, and IA-64. In fact, the next step will be to add support for the non-x86 architectures rather than adding functionality. This will put everybody back to the same level.

Again, this is not lost, and you will not have to do this again. I will provide the patchset for SPARC and others. I will simply need help testing this as I don't own SPARC systems. This applies for pfmon and libpfm as well.

This was not easy to accept for me either. I and many other people have put a lot of efforts in the current perfmon v2 codebase. Earlier this year, I was told that I had to start from scratch again because the patch was too big and too complicated. That's what I did with perfmon v3. I have addressed all the issues there were raised on LKML, going as far as making this release not backward compatible with perfmon v2.

I do appreciate your effort which I find quite exceptional. I give you credits for the SPARC support in each presentation I do. I do maintain the SPARC codebase to the best of my abilities. I will not give up on it, same thing with the other architectures. Each one must benefit from the new features offered by perfmon and we have proven they can.

In summary, what was posted on LKML is just the first piece. Once this is in, I will push the patches to add support for the other architectures as well. Your effort is not lost, your code is still maintained and will be used for the SPARC patchset. The same applies to other people who have contributed for Power and MIPS.

As you know, I have been involved with this project for quite some time now. I have been through many ups and downs trying to get this merged upstream. So rest assured of my full determination to bring this to the point of success.

Thanks.

I've been following this at a high level since using perfmon on ia64 several years ago. I have to say I'm impressed that you've put up with all the review and code churn (which to me often seemed arbitrary) without burning out.

Honestly I think it sucks that perfmonN isn't upstream yet supporting all the various architectures you've been working with. You've obviously proven to be a much more responsive and end-user focused maintainer than several of the other fly by night profiling infrastructures we currently have in the kernel (the long abandoned oprofile and perfctr come to mind).

As I mentioned at KS, I think it's about time we had a single point of contact for profiling in the kernel, to avoid the massive functional duplication we have today and make sure some kind of code sharing occurs; seems to me you'd be a good candidate for that sort of job.

But regardless, I think it's about time this got merged. Linus? Andrew?

Thanks,
Jesse

It is several years late. For me the problem has been that we do a lot of review and have lots of discussion but then the trail goes cold for six months and when it all pops up again the code has changed and/or we've all forgotten about it again.

What it needs is a sustained effort to get it over the hump. How's about getting it into linux-next asap and then we all agree to do the re-re-re-review and runtime testing for a 2.6.29 merge?

Andrew,

The kind of changes I have made following ealier reviews are not trivial, It takes time and I do other things as well. So I could not really post on LKML every week with something that would work and be worthy of your time.

Let's do this, then.

Thanks.

Stephane,

I have just looked through this set of patches and it mostly looks fine to me. There is just one thing, and that is that the way you access bitmaps using cast_ulp() won't work on 32-bit big-endian machines such as 32-bit PowerPC. I suggest that instead of using cast_ulp(), you have a set of abstracted bit-vector operations that can be implemented by the arch code - and on x86/ia64, they would be implemented with cast_ulp() + test_bit/__set_bit/etc. as at present.

I hope we can get these patches into 2.6.29.

Regards,
Paul.

Paul,

Thanks for bringing this up. I think we had talked about this a while back.

There is indeed a problem on big endian 32-bit machines The cast will pick up the wrong half of the u64. I think the best solution to this problem is as you suggested. Consequently, I have added a perfmon abstraction (bv) with its set of arch callbacks. The API takes u64 *.On x86, IA-64, it simply calls the bitmap_*() API. On PPC, it will have to adjust when compiling for 32 bits.

Here is the example of __set_bit() on x86:

static inline void pfm_arch_bv_set_bit(int b, u64 *a)

{
        __set_bit(b, (unsigned long *)a);
}

I will push this into my linux-next tree and ask Stephen to pull from it again.

Stephen,

I have updated the linux-next tree to fix the issue brought up by Paul.

Please pull from linux-next tree.

Thanks.