[patch 00/24] perfmon3: introduction - Kernel

This is a discussion on [patch 00/24] perfmon3: introduction - Kernel ; 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, ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [patch 00/24] perfmon3: introduction

  1. [patch 00/24] 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
    --

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [patch 00/24] perfmon3: introduction

    From: eranian@googlemail.com
    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...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [patch 00/24] perfmon3: introduction

    Dave,

    On Wed, Oct 22, 2008 at 6:25 AM, David Miller wrote:
    > From: eranian@googlemail.com
    > 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [patch 00/24] perfmon3: introduction

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [patch 00/24] perfmon3: introduction

    On Wed, 22 Oct 2008 09:58:22 -0700 Jesse Barnes 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?


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [patch 00/24] perfmon3: introduction

    Andrew,

    On Wed, Oct 22, 2008 at 7:22 PM, Andrew Morton
    wrote:
    > On Wed, 22 Oct 2008 09:58:22 -0700 Jesse Barnes 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [patch 00/24] perfmon3: introduction

    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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [patch 00/24] perfmon3: introduction

    Paul,

    On Mon, Nov 10, 2008 at 3:41 AM, Paul Mackerras 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [patch 00/24] perfmon3: introduction

    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
    wrote:
    > Paul,
    >
    > On Mon, Nov 10, 2008 at 3:41 AM, Paul Mackerras 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.
    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread