Re: systemtap memory usage

[Martin Hunt <hunt at redhat dot com>]

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.

> > Hitachi is proposing having only one set of system-wide transport
> > buffers shared among all systemtap scripts. This saves some memory at
> > the cost of performance.
> 
> As far as I know, current runtime uses per-cpu buffer for storing
> messages instead of lock. So I think this patch has no effect
> on performance.
>
> > It would also require some radical changes to
> > our architecture. staprun becomes stpd again and it downloads all
> > systemtap data, and distributes it among multiple registered clients...
> > I have doubts the performance cost will be acceptable to everyone.
> 
> That is a simple concept-level patch, and it just adds two compile option
> (-DRELAY_HOST and -DRELAY_GUEST). So, that will be enabled only if the
> user specify those options to stap. Other users might not care about that.
> Thus, I think there is no need to change the staprun.

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.  

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?

Martin