[PATCH] fix up perfmon to build on -mm - Kernel

This is a discussion on [PATCH] fix up perfmon to build on -mm - Kernel ; Stephane Eranian wrote: > Hello, > > On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote: >> Robert Richter wrote: >>> On 10.11.07 21:32:39, Andi Kleen wrote: >>>> It would be really good to extract a core perfmon ...

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 113

Thread: [PATCH] fix up perfmon to build on -mm

  1. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    Stephane Eranian wrote:
    > Hello,
    >
    > On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
    >> Robert Richter wrote:
    >>> On 10.11.07 21:32:39, Andi Kleen wrote:
    >>>> It would be really good to extract a core perfmon and start with
    >>>> that and then add stuff as it makes sense.
    >>>>
    >>>> e.g. core perfmon could be something simple like just support
    >>>> to context switch state and initialize counters in a basic way
    >>>> and perhaps get counter numbers for RDPMC in ring3 on x86[1]
    >>> Perhaps a core could provide also as much functionality so that
    >>> Perfmon can be used with an *unpatched* kernel using loadable modules?
    >>> One drawback with today's Perfmon is that it can not be used with a
    >>> vanilla kernel. But maybe such a core is by far too complex for a
    >>> first merge.
    >>>
    >>> -Robert
    >>>

    >> Hi Robert,
    >>
    >> In the past I suggested that it might be useful to have a version of perfmon2
    >> that only set up the perfmon on a global basis. That would allow the patches for
    >> context switches to be added as a separate step, splitting up the patch into
    >> smaller set of patches.
    >>
    >> Perfmon2 uses a set of system calls to control the performance monitoring
    >> hardware. This would make it difficult to use an unpatch kernel unless perfmon
    >> changed the mechanism used to control the performance monitoring hardware.
    >>

    > Yes, that would be a possibility but as you pointed out there are some problems:
    >
    > - perfmon2 uses system calls. So unless you can dynamically patch the
    > syscall table we would have to go back to the ioctl() and driver model.
    > I was under the impression that people did not quite like multiplexing
    > syscalls such as ioctl(). I also do prefer the multi syscall approach.
    >
    > - perfmon2 needs to install a PMU interrupt handler. On X86, this is not just
    > an external device interrupts. There needs to be some APIC and interrupt
    > gate setup. There maybe other constraints on other architectures as well.
    > Not sure if all functions/structures necessary for this are available to
    > modules.


    The oprofile module can setup a handler for PMU interrupts. This is done in
    archi/x86/oprofile/nmi_int:nmi_cpu_setup(). Other modules could do the same.
    However, it bumps what ever was using the nmi/pmu off, then restores nmi/pmu
    when oprofile is shut down. Maybe the pmu/nmi resource reservation mechanism
    should be another self-contained patch.

    > - we could not support per-thread mode with the kernel module approach due to
    > link to the context switch code. I do believe per-thread is a key value-add
    > for performance monitoring.


    The per-thread monitoring is useful to a number of people and many people want
    it. The thought was how to break the large perfmon patch into set of smaller
    incremental patches. So it isn't whether to have per-thread pmu virtualization,
    but rather when/how to get it in.

    -Will
    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
    > Hi folks,
    >
    > Well, I can say the mood here at supercomputing'07 is pretty somber in
    > regards to the latest exchange of messages regarding the perfmon patches.


    "somber"?

    Why?

    We (a number of the kernel developers) want to see the perfmon code make
    it into the kernel tree, unfortunatly, in the current state it is in,
    that's not going to happen.

    Andi specified a way that this can happen, just refactor your patches
    into smaller bits that can be reviewed and applied.

    If you, or anyone else has any questions about this, please let us know.
    So far, I have not seen any response to his message, so I'm guessing
    that the perfmon developers either are off working on this, or don't
    care.

    And if they don't care, then yes, I agree with your "somber" feeling...

    thanks,

    greg k-h
    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, 13 Nov 2007 10:59:24 -0800 Greg KH wrote:

    > On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
    > > Hi folks,
    > >
    > > Well, I can say the mood here at supercomputing'07 is pretty somber in
    > > regards to the latest exchange of messages regarding the perfmon patches.

    >
    > "somber"?
    >
    > Why?
    >
    > We (a number of the kernel developers) want to see the perfmon code make
    > it into the kernel tree, unfortunatly, in the current state it is in,
    > that's not going to happen.
    >
    > Andi specified a way that this can happen, just refactor your patches
    > into smaller bits that can be reviewed and applied.
    >
    > If you, or anyone else has any questions about this, please let us know.
    > So far, I have not seen any response to his message, so I'm guessing
    > that the perfmon developers either are off working on this, or don't
    > care.
    >
    > And if they don't care, then yes, I agree with your "somber" feeling...
    >


    Well... Philip is (I assume) a numerical-computing guy and not a
    kernel-developing guy (probably a wise choice).

    He speaks for quite a few people - they have serious need for this feature
    but they've had to scruff around with out-of-tree patches for years to get
    it, and still there are problems.

    I was hoping that after the round of release-and-review which Stephane,
    Andi and I did about twelve months ago that we were on track to merge the
    perfmon codebase as-offered. But now it turns out that the sentiment is
    that the code simply has too many bells-and-whistles to be acceptable.

    My problem with that sentiment is that it is quite likely the case that
    those bells-n-whistles are actually useful and needed features. Perfmon
    has been out there for quite a few years and the code which is in there
    _should_ be in response to real-world in-the-field experience. Such
    requirements never go away.


    So. If what I am saying is correct then the best course of action would be
    for Stephane to help us all to understand what these features are and why
    we need them. The ideal way in which to do this is

    [patch] perfmon: core
    [patch] perfmon: whizzy feature #1
    [patch] perfmon: whizzy feature #2
    [patch] perfmon: whizzy feature #3

    etc. Where the changelog in each whizzy-feature-n explains what it does,
    why it does it and why our users need it.

    Whatever happens, perfmon is so big and so old and has been out-of-tree for
    so long that it's going to take a pile of work from lots of people to get
    any of it landed.

    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, Nov 13, 2007 at 12:07:28PM -0800, Andrew Morton wrote:
    >
    > So. If what I am saying is correct then the best course of action would be
    > for Stephane to help us all to understand what these features are and why
    > we need them. The ideal way in which to do this is
    >
    > [patch] perfmon: core
    > [patch] perfmon: whizzy feature #1
    > [patch] perfmon: whizzy feature #2
    > [patch] perfmon: whizzy feature #3
    >
    > etc. Where the changelog in each whizzy-feature-n explains what it does,
    > why it does it and why our users need it.


    I agree. Right now their git tree has over 80 patches in it, without
    descriptions like this to help those of us who want to review and help
    out, it is quite difficult.

    thanks,

    greg k-h
    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    > He speaks for quite a few people - they have serious need for this feature

    Most likely they have serious need for a very small subset of perfmon2.
    The point of my proposal was to get this very small subset in quickly.

    Phil, how many of the command line options of pfmon do you
    actually use? How many do the people at your conference use? Or what
    functions, what performance counters etc. in PAPI or whatever
    library you use?

    Make use understand the use cases better, that would already help a lot
    in merging by concentrating on what people actually really need.

    -Andi

    -
    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: [perfmon2] perfmon2 merge news

    > In the past I suggested that it might be useful to have a version of
    > perfmon2 that only set up the perfmon on a global basis. That would allow


    Context switch is imho the main differentiating feature of perfmon
    over oprofile. Not sure it makes sense to take that one out.

    I don't think the complexity of the patches comes from the context
    switch anyways, it comes from the lots of other things it does.

    -Andi
    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    Will,

    On Tue, Nov 13, 2007 at 01:33:55PM -0500, William Cohen wrote:
    >
    > The oprofile module can setup a handler for PMU interrupts. This is done in
    > archi/x86/oprofile/nmi_int:nmi_cpu_setup(). Other modules could do the
    > same. However, it bumps what ever was using the nmi/pmu off, then restores
    > nmi/pmu when oprofile is shut down. Maybe the pmu/nmi resource reservation
    > mechanism should be another self-contained patch.
    >


    Oprofile does not setup the PMU interrupt. It builds on top of the NMI watchdog
    setup. It uses the register_die() mechanism, if I recall. The low level APIC
    and gate is setup elsewhere. Perfmon does not use NMI, unless forced to because
    of the NMI watchdog.


    > > - we could not support per-thread mode with the kernel module
    > > approach due to
    > > link to the context switch code. I do believe per-thread is a key
    > > value-add
    > > for performance monitoring.

    >
    > The per-thread monitoring is useful to a number of people and many people
    > want it. The thought was how to break the large perfmon patch into set of
    > smaller incremental patches. So it isn't whether to have per-thread pmu
    > virtualization, but rather when/how to get it in.


    I think we all agree on this.

    --

    -Stephane
    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, Nov 13, 2007 at 01:13:45PM -0800, Stephane Eranian wrote:
    > Oprofile does not setup the PMU interrupt. It builds on top of the NMI watchdog
    > setup.


    Oprofile works without the NMI watchdog too, but it just happens to be another
    NMI user.

    > It uses the register_die() mechanism,


    Not correct.

    > if I recall. The low level APIC
    > and gate is setup elsewhere. Perfmon does not use NMI, unless forced to because
    > of the NMI watchdog.


    It could handle it in the same way as oprofile if it wanted. But given
    NMIs make everything more complicated and it might not be worth it.

    -Andi
    -
    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: [perfmon] Re: [perfmon2] perfmon2 merge news

    Greg,

    On Tue, Nov 13, 2007 at 10:59:24AM -0800, Greg KH wrote:
    > On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
    > > Hi folks,
    > >
    > > Well, I can say the mood here at supercomputing'07 is pretty somber in
    > > regards to the latest exchange of messages regarding the perfmon patches.

    >
    > "somber"?
    >


    I am the core developer of this and I am not as pessimistic as Phil. Yet I admit
    Phil has been asking for this kind of kernel interface for a very very long time ;-<

    > Why?
    >
    > We (a number of the kernel developers) want to see the perfmon code make
    > it into the kernel tree, unfortunatly, in the current state it is in,
    > that's not going to happen.
    >
    > Andi specified a way that this can happen, just refactor your patches
    > into smaller bits that can be reviewed and applied.
    >


    I think I understand your concerns. I will work on this. I think it is possible to
    refactor. It will certainly be painful (for me), but I think it can be done within
    some reasonable delay. Of course, it would be help if you could better qualify what
    you mean by 'smaller'.

    > If you, or anyone else has any questions about this, please let us know.
    > So far, I have not seen any response to his message, so I'm guessing
    > that the perfmon developers either are off working on this, or don't
    > care.
    >


    I will start working on this once I fix the tickless/hrtimer issues.

    > And if they don't care, then yes, I agree with your "somber" feeling...
    >


    I do care a lot actually. Believe me, I do spend a lot of effort and energy
    on this project everyday, like many others around the world, and I intend for
    it to succeed. We have reached a point in the development of processor hardware
    where this kind of features is crucial and it is not just for HPC folks anymore.

    --
    -Stephane
    -
    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/

  10. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, Nov 13, 2007 at 01:33:13PM -0800, Stephane Eranian wrote:
    > I think I understand your concerns. I will work on this. I think it is possible to
    > refactor. It will certainly be painful (for me), but I think it can be done within
    > some reasonable delay. Of course, it would be help if you could better qualify what
    > you mean by 'smaller'.


    I think Andrew already spelled this out. If after reading his message,
    you still have questions, please let me know and I'll be glad to work
    with you to address them.

    thanks,

    greg k-h
    -
    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/

  11. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    Andi.

    On Tue, Nov 13, 2007 at 10:29:02PM +0100, Andi Kleen wrote:
    > On Tue, Nov 13, 2007 at 01:13:45PM -0800, Stephane Eranian wrote:
    > > Oprofile does not setup the PMU interrupt. It builds on top of the NMI watchdog
    > > setup.

    >
    > Oprofile works without the NMI watchdog too, but it just happens to be another
    > NMI user.
    >

    I have no doubt it can work with a "regular" interrupt.

    > > It uses the register_die() mechanism,

    >
    > Not correct.
    >

    I meant the register_die_notifier() mechanism which allow you to
    chain a handler on NMI interrupts. At least that's my understanding
    reading the code:

    static int nmi_setup(void)
    {
    int err=0;
    int cpu;

    if (!allocate_msrs())
    return -ENOMEM;

    if ((err = register_die_notifier(&profile_exceptions_nb))){
    free_msrs();
    pfm_release_allcpus();
    return err;
    }
    ...


    > > if I recall. The low level APIC
    > > and gate is setup elsewhere. Perfmon does not use NMI, unless forced to because
    > > of the NMI watchdog.

    >
    > It could handle it in the same way as oprofile if it wanted. But given
    > NMIs make everything more complicated and it might not be worth it.
    >

    Yes, horribly more complicated because of locking issues within perfmon.
    As soon as you expose a file descriptor, you need some locking to prevent
    multiple user threads (malicious or not) to compete to access the PMU state.
    I think the value add of NMI can be as well achieved with advanced PMU features
    such as Intel Core 2 PEBS.

    --
    -Stephane
    -
    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/

  12. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    > Yes, horribly more complicated because of locking issues within perfmon.
    > As soon as you expose a file descriptor, you need some locking to prevent
    > multiple user threads (malicious or not) to compete to access the PMU state.


    Why do you need the file descriptor?

    One of the main problems with perfmon is the complicated user interface.

    Naively I would assume just some thread global state should be sufficient.

    > I think the value add of NMI can be as well achieved with advanced PMU features
    > such as Intel Core 2 PEBS.


    True probably, although only on CPUs that support PEBS. Dropping features
    for old CPUs is unfortunately quite difficult in Linux, and in this case
    probably not an option because there are so many of them (e.g. all of AMD
    not Fam10h)

    -Andi
    -
    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/

  13. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    Andi,
    On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
    > > Yes, horribly more complicated because of locking issues within perfmon.
    > > As soon as you expose a file descriptor, you need some locking to prevent
    > > multiple user threads (malicious or not) to compete to access the PMU state.

    >
    > Why do you need the file descriptor?
    >


    To identify your monitoring session be it system-wide (i.e., per-cpu) or per-thread.
    file descriptor allows you to use close, read, select, poll and you leverage the
    existing file descriptor sharing/inheritance sematics. At the kernel level, a
    descriptor provides all the callback necessary to make sure you clean up the perfmon
    session state on exit.


    > One of the main problems with perfmon is the complicated user interface.
    >
    > Naively I would assume just some thread global state should be sufficient.
    >
    > > I think the value add of NMI can be as well achieved with advanced PMU features
    > > such as Intel Core 2 PEBS.

    >
    > True probably, although only on CPUs that support PEBS. Dropping features
    > for old CPUs is unfortunately quite difficult in Linux, and in this case
    > probably not an option because there are so many of them (e.g. all of AMD
    > not Fam10h)
    >


    Yes, I know that. Also note that unfortunately, AMD Fam10h IBS feature does not
    allow you to capture more than one sample in critical sections. It is still
    interrupt based sampling with one entry-deep buffer: one interrupt = one sample.
    Perfmon does support NMI though it is much more expensive to use.

    --
    -Stephane
    -
    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/

  14. Re: [perfmon] Re: [perfmon2] perfmon2 merge news



    What about investing some effort to do a proper performance counter
    infrastructure or turning the mess perfom is into one instead of this
    useless rant? Code is not getting any better by your complain ccing
    gazillions of useless list.
    -
    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/

  15. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, Nov 13, 2007 at 02:22:34PM -0800, Stephane Eranian wrote:
    > Andi,
    > On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
    > > > Yes, horribly more complicated because of locking issues within perfmon.
    > > > As soon as you expose a file descriptor, you need some locking to prevent
    > > > multiple user threads (malicious or not) to compete to access the PMU state.

    > >
    > > Why do you need the file descriptor?
    > >

    >
    > To identify your monitoring session be it system-wide (i.e., per-cpu) or per-thread.
    > file descriptor allows you to use close, read, select, poll and you leverage the


    Surely that could be done with a flag for each call too? Keeping file descriptors
    to pass essentially a boolean seems overkill.

    > existing file descriptor sharing/inheritance sematics. At the kernel level, a
    > descriptor provides all the callback necessary to make sure you clean up the perfmon
    > session state on exit.


    Didn't you already have a thread destructor for it?

    -Andi
    -
    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/

  16. Re: perfmon2 merge news

    On Tue, Nov 13, 2007 at 10:32:39AM -0800, Stephane Eranian wrote:
    > It would obvisouly cause a lot of troubles to existing perfmon libraries and
    > applications (e.g. PAPI). It would also be fairly tricky to do because you'd
    > have to make sure that in the beginning, you leave enough flexiblity such that
    > you can add the rest while maintaining total backward compatibility. But given
    > that we already have the full solution, it could just be a matter of dropping
    > features without disrupting the user level API.


    There no way we'll keep this completely idiotic userland API. If people start
    to use out of tree APIs they can pretty much expect that they're not going
    to stay around. And in this case they most certainly won't.

    -
    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/

  17. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    Andi,

    On Tue, Nov 13, 2007 at 11:25:34PM +0100, Andi Kleen wrote:
    > On Tue, Nov 13, 2007 at 02:22:34PM -0800, Stephane Eranian wrote:
    > > Andi,
    > > On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
    > > > > Yes, horribly more complicated because of locking issues within perfmon.
    > > > > As soon as you expose a file descriptor, you need some locking to prevent
    > > > > multiple user threads (malicious or not) to compete to access the PMU state.
    > > >
    > > > Why do you need the file descriptor?
    > > >

    > >
    > > To identify your monitoring session be it system-wide (i.e., per-cpu) or per-thread.
    > > file descriptor allows you to use close, read, select, poll and you leverage the

    >
    > Surely that could be done with a flag for each call too? Keeping file descriptors
    > to pass essentially a boolean seems overkill.
    >


    I don't understand this.

    Let's take the simplest possible example (self-monitoring per-thread)
    counting one event in one data register.

    int
    main(int argc, char **argv)
    {
    int ctx_fd;
    pfarg_pmd_t pd[1];
    pfarg_pmc_t pc[1];
    pfarg_ctx_t ctx;
    pfarg_load_t load_args;

    memset(&ctx, 0, sizeof(ctx));
    memset(pc, 0, sizeof(pc));
    memset(pd, 0, sizeof(pd));

    /* create session (context) and get file descriptor back (identifier) */
    ctx_fd = pfm_create_context(&ctx, NULL, NULL, 0);

    /* setup one config register (PMC0) */
    pc[0].reg_num = 0
    pc[0].reg_value = 0x1234;

    /* setup one data register (PMD0) */
    pd[0].reg_num = 0;
    pd[0].reg_value = 0;

    /* program the registers */
    pfm_write_pmcs(ctx_fd, pc, 1);
    pfm_write_pmds(ctx_fd, pd, 1);

    /* attach the context to self */
    load_args.load_pid = getpid();
    pfm_load_context(ctx_fd, &load_args);

    /* activate monitoring */
    pfm_start(ctx_fd, NULL);

    /*
    * run code to measure
    */

    /* stop monitoring */
    pfm_stop(ctx_fd);

    /* read data register */
    pfm_read_pmds(ctx_fd, pd, 1);

    printf("PMD0 %llu\n", pd[0].reg_value);

    /* destroy session */
    close(ctx_fd);

    return 0;
    }

    --

    -Stephane
    -
    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/

  18. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    Hi Andi,

    pfmon is a single tool and fairly low level, the HPC folks don't use
    it so much because it isn't parallel aware and is meant for power-
    users. It is not representative of the tools used in HPC at all. Our
    community uses tools built on the infrastructure provided by libpfm
    and PAPI for the most part.

    I know you don't want to hear this, but we actually use all of the
    features of perfmon, because a) we wanted to use the best methods
    available and b) areas where user level solutions could be made (like
    multiplexing) introduced too much noise and overhead to be of use.
    For years we relied on PerfCtr which did 'just enough' for us. But
    when Perfmon2 became available, we adopted technology where it meant
    a significant increase in accuracy for the resulting measurements,
    specifically for us that meant, kernel multiplexing and sample buffers.
    Note that PAPI is just middleware. The tools built upon it are what
    people use...some of those are commercial tools like Vampir but most
    are Open Source. These tools are cross platform, as such they run on
    nearly everything...although intel/amd/ppc systems dominate the HPC
    market.

    The usage cases are always the same and can be broken down into
    simple counting and sampling:

    - providing virtualized 64-bit counters per-thread
    - providing notification (buffered or non) on interrupt/overflow of
    the above.

    If you'd like to outline further what you'd like to hear from the
    community, I can arrange that. I seem to remember going through this
    once before, but I'd be happy to do it again. For reference, here's a
    quick list from memory of some of the tools in active use and built
    on this infrastructure. These are used heavily around the globe.
    You'll see that each basically follows one of the 2 usage models above.

    - HPCToolkit (Rice)
    - PerfSuite (NCSA)
    - Vampir (Dresden)
    - Kojak (Juelich)
    - TAU (UOregon)
    - PAPIEX (me)
    - GPTL (NCAR)
    - HPM-Linux (IBM)
    - Paraver (Barcelona)

    Time to go give a talk here at a tools session at SC'07 about this
    very subject.

    Phil

    On Nov 13, 2007, at 12:36 PM, Andi Kleen wrote:

    >> He speaks for quite a few people - they have serious need for this
    >> feature

    >
    > Most likely they have serious need for a very small subset of
    > perfmon2.
    > The point of my proposal was to get this very small subset in quickly.
    >
    > Phil, how many of the command line options of pfmon do you
    > actually use? How many do the people at your conference use? Or what
    > functions, what performance counters etc. in PAPI or whatever
    > library you use?
    >
    > Make use understand the use cases better, that would already help a
    > lot
    > in merging by concentrating on what people actually really need.
    >
    > -Andi
    >


    -
    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/

  19. Re: [perfmon] Re: [perfmon2] perfmon2 merge news

    On Tue, Nov 13, 2007 at 04:28:52PM -0800, Philip Mucci wrote:
    > I know you don't want to hear this, but we actually use all of the
    > features of perfmon, because a) we wanted to use the best methods


    That is hard to believe.

    But let's go for it temporarily for the argument.

    Can you instead prioritize features. What is most essential, what is
    important, what is just nice to have, what is rarely used?

    > Note that PAPI is just middleware. The tools built upon it are what


    Surely the tools on top cannot use more than the middleware provides.

    > - providing virtualized 64-bit counters per-thread
    > - providing notification (buffered or non) on interrupt/overflow of
    > the above.


    Ok that makes sense and should be possible with a reasonable simple
    interface.

    > If you'd like to outline further what you'd like to hear from the
    > community, I can arrange that. I seem to remember going through this
    > once before, but I'd be happy to do it again. For reference, here's a
    > quick list from memory of some of the tools in active use and built
    > on this infrastructure. These are used heavily around the globe.


    Please list concrete features, throwing around random names is not useful.

    -Andi

    -
    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/

  20. Re: [perfmon] Re: [perfmon2] perfmon2 merge news


    [dropped all these bouncing email lists. Adding closed lists to public
    cc lists is just a bad idea]

    > int
    > main(int argc, char **argv)
    > {
    > int ctx_fd;
    > pfarg_pmd_t pd[1];
    > pfarg_pmc_t pc[1];
    > pfarg_ctx_t ctx;
    > pfarg_load_t load_args;
    >
    > memset(&ctx, 0, sizeof(ctx));
    > memset(pc, 0, sizeof(pc));
    > memset(pd, 0, sizeof(pd));
    >
    > /* create session (context) and get file descriptor back (identifier) */
    > ctx_fd = pfm_create_context(&ctx, NULL, NULL, 0);


    There's nothing in your example that makes the file descriptor needed.

    >
    > /* setup one config register (PMC0) */
    > pc[0].reg_num = 0
    > pc[0].reg_value = 0x1234;


    That would be nicer if it was just two arguments.

    >
    > /* setup one data register (PMD0) */
    > pd[0].reg_num = 0;
    > pd[0].reg_value = 0;


    Why do you need to set the data register? Wouldn't it make
    more sense to let the kernel handle that and just return one.

    >
    > /* program the registers */
    > pfm_write_pmcs(ctx_fd, pc, 1);
    > pfm_write_pmds(ctx_fd, pd, 1);
    >
    > /* attach the context to self */
    > load_args.load_pid = getpid();
    > pfm_load_context(ctx_fd, &load_args);


    My replacement would be to just add a flags argument to write_pmcs
    with one flag bit meaning "GLOBAL CONTEXT" versus "MY CONTEXT"
    >
    > /* activate monitoring */
    > pfm_start(ctx_fd, NULL);


    Why can't that be done by the call setting up the register?

    Or if someone needs to do it for a specific region they can read
    the register before and then afterwards.

    >
    > /*
    > * run code to measure
    > */
    >
    > /* stop monitoring */
    > pfm_stop(ctx_fd);
    >
    > /* read data register */
    > pfm_read_pmds(ctx_fd, pd, 1);


    On x86 i think it would be much simpler to just let the set/alloc
    register call return a number and then use RDPMC directly. That would
    be actually faster and be much simpler too.

    I suppose most architectures have similar facilities, if not a call could be
    added for them but it's not really essential. The call might be also needed
    for event multiplexing, but frankly I would just leave that out for now.

    e.g. here is one use case I would personally see as useful. We need
    a replacement for simple cycle counting since RDTSC doesn't do that anymore
    on modern x86 CPUs. It could be something like:

    /* 0 is the initial value */

    /* could be either library or syscall */
    event = get_event(COUNTER_CYCLES);
    if (event < 0)
    /* CPU has no cycle counter */

    reg = setup_perfctr(event, 0 /* value */, LOCAL_EVENT); /* syscall */

    rdpmc(reg, start);
    .... some code to run ...
    rdpmc(reg, end);

    free_perfctr(reg); /* syscall */

    On other architectures rdpmc would be different of course, but
    the rest could be probably similar.

    -Andi

    -
    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
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast