[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080723005002.GA5206@localhost>
Date: Wed, 23 Jul 2008 03:50:02 +0300
From: Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To: "Frank Ch. Eigler" <fche@...hat.com>
Cc: penberg@...helsinki.fi, cl@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
rdunlap@...otime.net, mpm@...enic.co
Subject: 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 <eduard.munteanu@...ux360.ro> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists