[RFC PATCH 0/4] kmemtrace RFC (resend 2) - Kernel

This is a discussion on [RFC PATCH 0/4] kmemtrace RFC (resend 2) - Kernel ; Hi everyone, I hopefully fixed all your previous objections. I have also set up a git tree for anyone who'd like to try kmemtrace (gitweb URL): http://repo.or.cz/w/linux-2.6/kmemtrace.git Comment on the patchset and please try running kmemtrace if possible. Check the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [RFC PATCH 0/4] kmemtrace RFC (resend 2)

  1. [RFC PATCH 0/4] kmemtrace RFC (resend 2)

    Hi everyone,

    I hopefully fixed all your previous objections. I have also set up a git tree
    for anyone who'd like to try kmemtrace (gitweb URL):

    http://repo.or.cz/w/linux-2.6/kmemtrace.git

    Comment on the patchset and please try running kmemtrace if possible. Check
    the docs for information on how to get the userspace tool and set it up.

    Important: the kmemtrace-user repo went stable and I'll not alter the revision
    history anymore. BTW, don't be scared if you see many errors being reported by
    kmemtrace-report, this is a known issue (I could use some advice on this if
    you know what's going on).

    Changes since last submission:
    1. fixed allocator tracing
    2. wrote more documentation
    3. reworked the ABI and documented it in Documentation/ABI; we don't include
    kernel headers in userspace anymore
    4. added support for disabling kmemtrace at boot-time
    5. added provisions for disabling kmemtrace at runtime
    6. changed slab allocators to use __always_inline instead of plain inline,
    so that we're sure the return address is valid
    7. removed some useless cast, as pointed out by Pekka Enberg

    Since the changes were quite extensive, I chose not to preserve any tags such
    as "Reviewed-by".

    I'm waiting for your input on this.


    Thanks,
    Eduard

    P.S.: Pekka, I followed your advice on adding a field containing the struct
    size (managed to make room for it without adding to the current struct size).
    This allows us to do crazy stuff in the future, like exporting the whole
    stack trace on every allocation. Not sure how useful this is right now, but
    let's keep the ABI extensible.


    Eduard - Gabriel Munteanu (4):
    kmemtrace: Core implementation.
    kmemtrace: SLAB hooks.
    kmemtrace: SLUB hooks.
    kmemtrace: SLOB hooks.

    Documentation/ABI/testing/debugfs-kmemtrace | 58 +++++++
    Documentation/kernel-parameters.txt | 10 +
    Documentation/vm/kmemtrace.txt | 126 ++++++++++++++
    MAINTAINERS | 6 +
    include/linux/kmemtrace.h | 110 ++++++++++++
    include/linux/slab_def.h | 68 +++++++-
    include/linux/slob_def.h | 9 +-
    include/linux/slub_def.h | 53 ++++++-
    init/main.c | 2 +
    lib/Kconfig.debug | 28 +++
    mm/Makefile | 2 +-
    mm/kmemtrace.c | 244 +++++++++++++++++++++++++++
    mm/slab.c | 71 +++++++-
    mm/slob.c | 37 ++++-
    mm/slub.c | 66 +++++++-
    15 files changed, 854 insertions(+), 36 deletions(-)
    create mode 100644 Documentation/ABI/testing/debugfs-kmemtrace
    create mode 100644 Documentation/vm/kmemtrace.txt
    create mode 100644 include/linux/kmemtrace.h
    create mode 100644 mm/kmemtrace.c

    --
    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: [RFC PATCH 1/4] kmemtrace: Core implementation.


    Eduard - Gabriel Munteanu writes:

    > kmemtrace provides tracing for slab allocator functions, such as kmalloc,
    > kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected data is then fed
    > to the userspace application in order to analyse allocation hotspots,
    > internal fragmentation and so on, making it possible to see how well an
    > allocator performs, as well as debug and profile kernel code.
    > [...]


    It may make sense to mention in addition that this version of
    kmemtrace uses markers as the low-level hook mechanism, and this makes
    the data generated directly accessible to other tracing tools such as
    systemtap. Thank you!


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

  3. Re: [RFC PATCH 1/4] kmemtrace: Core implementation.

    On Wed, Jul 23, 2008 at 03:50:02AM +0300, Eduard - Gabriel Munteanu wrote:
    > On Tue, Jul 22, 2008 at 05:28:16PM -0400, Frank Ch. Eigler wrote:
    > >
    > > Eduard - Gabriel Munteanu writes:
    > >
    > > > kmemtrace provides tracing for slab allocator functions, such as kmalloc,
    > > > kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected data is then fed
    > > > to the userspace application in order to analyse allocation hotspots,
    > > > internal fragmentation and so on, making it possible to see how well an
    > > > allocator performs, as well as debug and profile kernel code.
    > > > [...]

    > >
    > > It may make sense to mention in addition that this version of
    > > kmemtrace uses markers as the low-level hook mechanism, and this makes
    > > the data generated directly accessible to other tracing tools such as
    > > systemtap. Thank you!
    > >
    > >
    > > - FChE

    >
    > Sounds like a good idea, but I'd like to get rid of markers and use
    > Mathieu Desnoyers' tracepoints instead. I'm just waiting for tracepoints
    > to get closer to inclusion in mainline/-mm.
    >
    > It would be great if tracepoints completely replaced markers, so SystemTap
    > would use those instead.
    >
    > However, if tracepoints are not ready when kmemtrace is to be merged,
    > I'll take your advice and mention markers and SystemTap.
    >
    >
    > Thanks,
    > Eduard
    >


    (fixed Matt's Cc.)

    --
    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: [RFC PATCH 1/4] kmemtrace: Core implementation.

    On Tue, Jul 22, 2008 at 05:28:16PM -0400, Frank Ch. Eigler wrote:
    >
    > Eduard - Gabriel Munteanu writes:
    >
    > > kmemtrace provides tracing for slab allocator functions, such as kmalloc,
    > > kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected data is then fed
    > > to the userspace application in order to analyse allocation hotspots,
    > > internal fragmentation and so on, making it possible to see how well an
    > > allocator performs, as well as debug and profile kernel code.
    > > [...]

    >
    > It may make sense to mention in addition that this version of
    > kmemtrace uses markers as the low-level hook mechanism, and this makes
    > the data generated directly accessible to other tracing tools such as
    > systemtap. Thank you!
    >
    >
    > - FChE


    Sounds like a good idea, but I'd like to get rid of markers and use
    Mathieu Desnoyers' tracepoints instead. I'm just waiting for tracepoints
    to get closer to inclusion in mainline/-mm.

    It would be great if tracepoints completely replaced markers, so SystemTap
    would use those instead.

    However, if tracepoints are not ready when kmemtrace is to be merged,
    I'll take your advice and mention markers and SystemTap.


    Thanks,
    Eduard

    --
    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: [RFC PATCH 1/4] kmemtrace: Core implementation.

    Hi -


    On Wed, Jul 23, 2008 at 03:50:02AM +0300, Eduard - Gabriel Munteanu wrote:

    > [...] Sounds like a good idea, but I'd like to get rid of markers
    > and use Mathieu Desnoyers' tracepoints instead. I'm just waiting for
    > tracepoints to get closer to inclusion in mainline/-mm.


    OK.

    > It would be great if tracepoints completely replaced markers, so
    > SystemTap would use those instead.


    Raw tracepoints are problematic as they require a per-tracepoint C
    function signature to be synthesized by the tool (or hard-coded in the
    tool or elsewhere). We haven't worked out how best do to this. OTOH,
    markers don't require such hard-coding, so are simpler for a general
    tool to interface to.


    > However, if tracepoints are not ready when kmemtrace is to be merged,
    > I'll take your advice and mention markers and SystemTap.


    Thanks either way - I'm glad you found an existing tracing mechanism
    usable and didn't choose/need to invent your own.


    - 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