This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some notes on translation


On Fri, 2005-02-25 at 12:09 -0600, Tom Zanussi wrote:

> OK, sounds like the netlink API is what I'll focus on for the time
> being.

Great!

> BTW, what's the thinking on stack dumps?  There's already code in the
> kernel for doing that - dump_stack(), but it's hard-coded to use
> printk.  If that code could be made to print into a separate buffer
> instead, it could be re-used for systemtap, but I doubt a change like
> that would be accepted into the kernel.

I noticed that.  My only thought was to reimplement dump_stack() for
each architecture in the runtime library.  Maybe someone has a better
idea.

> One of the really nifty things I thought DTrace did was allow a stack
> trace to be used as a hash key - you could for instance keep a counter
> in each hash entry and dump the keys to get an idea of the relative
> frequencies of particular execution paths to a given function.

Supporting that has caused me some real headaches.  I originally didn't
want to support arbitrary-size strings as hash keys because of the
memory management problems.  The simple way to do this is to kmalloc
(GFP_ATOMIC) for memory to save the string in, but we don't want to do
that.  Not doing it means preallocating a large static buffer and
allocating memory out of it for string storage. That is what I have
implemented so far.  Unfortunately it does not actually free memory that
is no longer used, so if keys change frequently, it will waste memory.
I think this will probably not be the normal case.

I think I will probably end up adding a malloc lib into the runtime.
 
Martin



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]