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

This is a discussion on [PATCH] fix up perfmon to build on -mm - Kernel ; On Fri, Nov 16, 2007 at 04:29:05PM -0800, David Miller wrote: > From: dean gaudet > Date: Fri, 16 Nov 2007 09:51:08 -0800 (PST) > > > On Fri, 16 Nov 2007, Andi Kleen wrote: > > > > > ...

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6
Results 101 to 113 of 113

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

  1. Re: perfmon2 merge news

    On Fri, Nov 16, 2007 at 04:29:05PM -0800, David Miller wrote:
    > From: dean gaudet
    > Date: Fri, 16 Nov 2007 09:51:08 -0800 (PST)
    >
    > > On Fri, 16 Nov 2007, Andi Kleen wrote:
    > >
    > > > I didn't see a clear list.

    > >
    > > - cross platform extensible API for configuring perf counters
    > > - support for multiplexed counters
    > > - support for virtualized 64-bit counters
    > > - support for PC and call graph sampling at specific intervals
    > > - support for reading counters not necessarily with sampling
    > > - taskswitch support for counters
    > > - API available from userland
    > > - ability to self-monitor: need select/poll/etc interface
    > > - support for PEBS, IBS and whatever other new perf monitoring
    > > infrastructure the vendors through at us in the future
    > > - low overhead: must minimize the "probe effect" of monitoring
    > > - low noise in measurements: cannot achieve this in userland
    > >
    > > permon2 has all of this and more i've probably neglected...

    >
    > I want to state that even though I've been a stickler on the system
    > call stuff, in general I want to see perfmon2 go into tree and I agree
    > with how most of the infrastructure is implemented and the features it
    > provides.


    Now if we only had a series of patches that we could actually review and
    apply to the -mm tree so that people can try them out...

    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/

  2. Re: perfmon2 merge news

    On Sat, Nov 17, 2007 at 02:13:13AM +0100, Patrick DEMICHEL wrote:
    > Yet another noisy linux HPC user
    >
    > I hope to convince you, lkml developers, to pay more attention to our HPC
    > performance problems.


    We do pay attention, and want to help out, we just need either bug
    reports of problems that we can work to address, or patches in a
    reviewable state whereby we are able to review, work with, and apply to
    our trees.

    Please do not think we are ignoring you at all, we are glad to work with
    anyone who uses the Linux kernel on whatever platform as we well know
    this allows us to create a kernel that works even better for everyone.

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

    On Sat, Nov 17, 2007 at 02:48:45AM +0100, Patrick DEMICHEL wrote:
    > Thanks Greg,
    >
    > but for external people it seems there is lot of people with opposite
    > opinions, for sure some are valid and they can be focused on different
    > things. But for example this critical topic seems quite not under control.
    > And we don't like that.
    > At least not under the control of Stephane, whatever the efforts if could
    > generate, we have the feeling we will never have something serious to us.
    > Also I never see a clear statement after long exchanges on what is the
    > accepted final common view of some topic like that
    > Maybe there is never definitive position, but a resume could be
    > interesting to make some reference point
    >
    > What I would like to see is:




    Heh, no, code is our currency here, it's the center of everything that
    we do and work with. Agreements, deadlines and plans are just not
    relevant at all here, sorry.

    So again, post the code, in reviewable patches, and then let's talk. A
    number of developers have expressed a concrete interest in getting this
    kind of feature into the kernel tree, so show us the code so that we can
    move forward.

    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/

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


    Instead of blabbering further about this topic, I decided to put my
    code where my mouth is and spent the weekend porting the perfmon2
    kernel bits, and the user bits (libpfm and pfmon) to sparc64.

    As a result I've found that perfmon2 is quite nice and allows
    incredibly useful and powerful tools to be written. The syscalls
    aren't that bad and really I see not reason to block it's inclusion.

    I rescind all of my earlier objections, let's merge this soon :-)
    -
    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

    David,

    On Mon, Nov 19, 2007 at 05:08:43AM -0800, David Miller wrote:
    >
    > Instead of blabbering further about this topic, I decided to put my
    > code where my mouth is and spent the weekend porting the perfmon2
    > kernel bits, and the user bits (libpfm and pfmon) to sparc64.
    >


    I appreciate your effort. I am glad to see that the interface
    and implementation survived yet another architecture. I think at this
    point ARM is the only major architecture missing. In anycase, I would
    be happy to integrate your sparc64 patches.

    > As a result I've found that perfmon2 is quite nice and allows
    > incredibly useful and powerful tools to be written. The syscalls
    > aren't that bad and really I see not reason to block it's inclusion.
    >


    As I said earlier, I am not opposed to changing the syscalls. I have
    proposed a few schemes to address the issue of versioning. If vectors
    arguments are problematic, we can go with single register/call.

    I think there are other areas where perfmon2 could benefit from the
    help of the LKML developers. I will post a list shortly.

    > I rescind all of my earlier objections, let's merge this soon :-)


    Thanks.

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

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

    David Miller writes:

    > As a result I've found that perfmon2 is quite nice and allows
    > incredibly useful and powerful tools to be written. The syscalls
    > aren't that bad and really I see not reason to block it's inclusion.
    >
    > I rescind all of my earlier objections, let's merge this soon :-)


    Strongly agree. However, I think we need to add structure size
    arguments to most of the syscalls so we can extend them later.

    Also, something I've been meaning to mention to Stephane is that the
    use of the cast_ulp() macro in perfmon is bogus and won't work on
    32-bit big-endian platforms such as ppc32 and sparc32. On such
    platforms you can't take a pointer to an array of u64, cast it to
    unsigned long * and expect the kernel bitmap operations to work
    correctly on it. At the least you also need to XOR the bit numbers
    with 32 on those platforms. Another alternative is to define the
    bitmaps as arrays of bytes instead, which eliminates all byte ordering
    and wordsize problems (but makes it more tricky to use the kernel
    bitmap functions directly).

    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/

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

    Paul,

    On Tue, Nov 20, 2007 at 08:43:32AM +1100, Paul Mackerras wrote:
    > David Miller writes:
    >
    > > As a result I've found that perfmon2 is quite nice and allows
    > > incredibly useful and powerful tools to be written. The syscalls
    > > aren't that bad and really I see not reason to block it's inclusion.
    > >
    > > I rescind all of my earlier objections, let's merge this soon :-)

    >
    > Strongly agree. However, I think we need to add structure size
    > arguments to most of the syscalls so we can extend them later.
    >

    Yes, that is one way. It works well if you only extend structures at the end.
    Given that you need to obtain the file descriptor first via a pfm_create_context
    call, an alternative could be that you pass a version number to that call to
    identify the version the application is requesting.

    > Also, something I've been meaning to mention to Stephane is that the
    > use of the cast_ulp() macro in perfmon is bogus and won't work on
    > 32-bit big-endian platforms such as ppc32 and sparc32. On such


    I don't like those cast_ulp() macros. They were put there to avoid compiler
    warnings on some architectures. Clearly with the big-endian issue, we need
    to find something else. The bitmap*() macros make unsigned long *.

    The interface uses fixed size type to ensure ABI compatibility between
    32 and 64 bit modes. This way there is no need to marhsall syscall arguments
    for a 32-bit app running on a 64-bit host.

    Looks like we will have to use bytes (u8) instead. This may have some
    performance impact as well. Several bitmaps are used in the context/interrupt
    routines. Even with u8, there is still a problem with the bitmap*() macros.
    Now, only a small subset of the bitmap() macros are used, so it may be okay
    to duplicate them for u8.

    What do you think?

    > platforms you can't take a pointer to an array of u64, cast it to
    > unsigned long * and expect the kernel bitmap operations to work
    > correctly on it. At the least you also need to XOR the bit numbers
    > with 32 on those platforms. Another alternative is to define the
    > bitmaps as arrays of bytes instead, which eliminates all byte ordering
    > and wordsize problems (but makes it more tricky to use the kernel
    > bitmap functions directly).
    >


    --

    -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

    From: Stephane Eranian
    Date: Mon, 19 Nov 2007 12:53:30 -0800

    > In anycase, I would be happy to integrate your sparc64 patches.


    I sent these to Philip Mucci late last night, but in the meantime
    I finished implementing breakpoint support as well for pfmon.

    Let me clean up my diffs and I'll send it all out to you in a
    few hours.
    -
    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

    From: Stephane Eranian
    Date: Mon, 19 Nov 2007 14:48:46 -0800

    > Looks like we will have to use bytes (u8) instead. This may have some
    > performance impact as well. Several bitmaps are used in the context/interrupt
    > routines. Even with u8, there is still a problem with the bitmap*() macros.
    > Now, only a small subset of the bitmap() macros are used, so it may be okay
    > to duplicate them for u8.


    I think it would be fine to just create a set of bitop interfaces that
    operate on u32 objects instead of "unsigned long".

    Currently perfmon2 does not need the atomic variants at all, and those
    could thus be provided entirely under include/asm-generic/bitops/
    -
    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: [perfmon2] perfmon2 merge news

    Hello,

    A few weeks back, I mentioned that I would post some
    interesting problems that I have encountered while
    implementing perfmon and for which I am still looking
    for better solutions.

    Here is one that I would like to solve right now and
    for which I am interested in your comments.

    One of the perfmon syscall (pfm_restart()) is used to
    resume monitoring after a user level notification. When
    operating in per-thread non self-monitoring mode, the
    syscall needs to operate on the machine state of the
    monitored thread. So you get into this situation:


    Thread T0 Thread T1
    | |
    pfm_restart() |
    | |
    spin_lock_irqsave() |
    | |
    --------------->|
    | |
    spin_unlock_irqrestore() |
    | |
    v v

    Thread T1 may be running at the time T0 needs to modify its state.
    The current solution is to set a TIF flag in T1. That TIF flag will
    cause T1 (on kernel exit) to go into a perfmon function that will
    then modify the state, i.e., state is self-modified. That works okay
    but there are a few race conditions. For self-monitoring sessions
    (e.g., system-wide or per-thread), it is easy because we operate in
    the correct thread.

    But there is a big difference between self-monitoring and non
    self-monitoring. The pfm_restart() syscall does not provide the
    same guarantee.

    In self-monitoring modes, the interface guarantees that by the time you
    return from the call, the effects of the call are visible. Whereas when
    monitoring another thread, the call currently does not provide such
    guarantee, i.e., it does not wait until T1 has seen the TIF flag and
    completed the state modification before returning. We could add a semaphore
    to enforce that guarantee but it gets difficult with corner cases and
    cleanups in case of unpexected termination.

    AFAIK, there is no single call to stop T1 and wait until it is completely
    off the CPU, unless we go through the (internal) ptrace interface.

    Would you have anything better to suggest?

    Thanks.

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

  11. Re: [perfmon2] perfmon2 merge news


    Stephane Eranian writes:

    > [...] AFAIK, there is no single call to stop T1 and wait until it
    > is completely off the CPU, unless we go through the (internal)
    > ptrace interface.


    The utrace code supports this style of thread manipulation better
    than ptrace.

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

    Charles,

    On Fri, Dec 14, 2007 at 02:12:17PM -0500, Frank Ch. Eigler wrote:
    >
    > Stephane Eranian writes:
    >
    > > [...] AFAIK, there is no single call to stop T1 and wait until it
    > > is completely off the CPU, unless we go through the (internal)
    > > ptrace interface.

    >
    > The utrace code supports this style of thread manipulation better
    > than ptrace.


    Afre you saying that utrace provides a utrace_thread_stop(tid) call
    that returns only when the thread tid is off the CPU. And then there
    is a utrace_thread_resume(tid) call. If that's the case then that is
    what I need.

    How are we with regards to utrace integration?

    Thanks.

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

  13. Re: [perfmon2] perfmon2 merge news

    Stephane Eranian writes:

    > [...]
    >> > [...] AFAIK, there is no single call to stop T1 and wait until it
    >> > is completely off the CPU, unless we go through the (internal)
    >> > ptrace interface.

    >>
    >> The utrace code supports this style of thread manipulation better
    >> than ptrace.

    >
    > Afre you saying that utrace provides a utrace_thread_stop(tid) call
    > that returns only when the thread tid is off the CPU. And then there
    > is a utrace_thread_resume(tid) call. If that's the case then that is
    > what I need.


    While I see no single call, it can be synthesized from a sequence of
    them: utrace_attach, utrace_set_flags (... UTRACE_ACTION_QUESCE ...),
    then waiting for a callback. Roland, is there a more compact way?

    > How are we with regards to utrace integration?


    Roland McGrath is working on breaking the patches down.

    - FChE
    --
    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 6 of 6 FirstFirst ... 4 5 6