Re: systemtap memory usage

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

Hi Martin,

Martin Hunt wrote:
> With the transport rewrite I am working on, we will eliminate the 2M
> procfs and perhaps limit relayfs to a single shared 1M or 2M buffer
> instead of percpu. (stap -b would still do per-cpu buffers for maximum
> performance). staprun is also much smaller.

Good news. It's very interesting for me.

> What next?
>
> 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

> The symbol and module database is a candidate to be eliminated if we can
> get either a few small changes to the kernel or we spin the code out
> into its own module.

The latter idea is similer to the idea which I described as bz#3858.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3858

I think, if we make a common runtime module which provides the interfaces
of the relay-channel and the symbol database, we can reduce memory cost
by sharing those resources and we can decide which script shares its
output channel or not. IMHO, if user minds performance rather than
memory usage, he can assign the channels to each script.

I suggest that we should provide this common runtime as a set of
source code. And then, stap checks whether the common runtime already
loaded, and if not, stap compiles the common runtime and loads it before
loading the script module.

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

Thanks,

-- 
Masami HIRAMATSU
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com