This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemtap memory usage
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Martin Hunt <hunt at redhat dot com>
- Cc: systemtap at sources dot redhat dot com, Satoshi Oshima <soshima at redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Hideo Aoki <haoki at redhat dot com>
- Date: Thu, 22 Feb 2007 19:24:00 +0900
- Subject: Re: systemtap memory usage
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <1171640857.5679.27.camel@dragon> <45DB8C73.3070405@hitachi.com> <1172073050.3446.23.camel@dragon>
Hi,
Martin Hunt wrote:
> On Wed, 2007-02-21 at 09:04 +0900, Masami Hiramatsu wrote:
>> Martin Hunt wrote:
>>> Clearly we should rethink having "stap" hang around.
>> stap and staprun could be detached from the kernel module, if you
>> apply my kernel flight-recorder patch attached to bz#3857.
>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=3857
>
> Yes, your patch will be part of the transport rewrite I am working on.
> However, normally staprun needs to be running to empty the buffers and
> record the incoming data to disk. stap on the other hand is not needed
> and can always be safely eliminated.
In that case, I think Frank's idea is good to us.
stap just does exec staprun and staprun reports consumed times after
running a compiled script.
[...]
> OK, I think I was looking at your request wrong. I was thinking about
> adding this as a general feature, where multiple unrelated systemtap
> scripts might be internally sharing a common relayfs buffer. That
> requires a stpd that can demultiplex the data streams and send them back
> to individual staprun clients. That's why I mentioned performance would
> be reduced.
OK, I see.
> But perhaps what you want is more of a special case to support your
> specific applications that use systemtap? In this case we don't have to
> worry about some other user(s) on your system writing data into the
> shared relayfs buffer or running another script with -DRELAY_HOST. And
> you will not be demultiplexing the data in userspace as it is received.
> Instead you just save it to a file and postprocess it with a custom
> application. Is this right?
Yes, that's right. Actually, that simple patch is just for a custom
tracing application only. And I posted the bz#3858 because I thought
you might prefer more general way to do that.
However, my main concern is to share a buffer among custom tracing
scripts like as LKET. For this purpose, I just need that simple feature.
Thanks,
--
Masami HIRAMATSU
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com