This is the mail archive of the 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: systemtap memory usage


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


Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory

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