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)
> Thanks to all the people who have contributed to this new release.
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,
On Wed, Oct 22, 2008 at 6:25 AM, David Miller <[email protected]> wrote:
> From: [email protected]
> Date: Fri, 17 Oct 2008 08:05:07 -0700 (PDT)
>
>> Thanks to all the people who have contributed to this new release.
>
> What about the folks who worked hard on sparc, powerpc, et al. perfmon
> support? Do they "just lose" for the moment? :-/
>
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.
> 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.
>
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.
> I definitely do not support this reincarnation, this is the last thing
> I expected to happen.
>
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.
> 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?
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.
On Wednesday, October 22, 2008 1:39 am stephane eranian wrote:
> 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.
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
On Wed, 22 Oct 2008 09:58:22 -0700 Jesse Barnes <[email protected]> wrote:
> On Wednesday, October 22, 2008 1:39 am stephane eranian wrote:
> > 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.
>
> 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?
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,
On Wed, Oct 22, 2008 at 7:22 PM, Andrew Morton
<[email protected]> wrote:
> On Wed, 22 Oct 2008 09:58:22 -0700 Jesse Barnes <[email protected]> wrote:
>
> 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.
>
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.
> 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?
>
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,
On Mon, Nov 10, 2008 at 3:41 AM, Paul Mackerras <[email protected]> wrote:
> 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.
>
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.
On Mon, Nov 10, 2008 at 4:24 PM, stephane eranian
<[email protected]> wrote:
> Paul,
>
> On Mon, Nov 10, 2008 at 3:41 AM, Paul Mackerras <[email protected]> wrote:
>> 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.
>>
>
> 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.
>