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]

[Bug runtime/3858] Independent Runtime Module

------- Additional Comments From masami dot hiramatsu dot pt at hitachi dot com  2007-01-26 13:54 -------
(In reply to comment #5)
> > I know I might merge the script sources. But sometimes (ex. running
> > systemtap on customer's servers), I can't do it and have to combine
> > the pre-compiled scripts.
> Could you explain why this merging needs to be done in kernel space?
> Why not in user-space after the fact?  If the individual scripts emit
> timestamps, it would be straightforward.  By merging in kernel space,
> we would probably be forcing all systemtap modules to synchronize

I think there is no need to apply this feature to all systemtap
modules. I'd like to make this feature selectable.
In my thought, you can specify -DTRANSPORT_MERGE option when we compile
the script which supports this feature, and give staprun the -O"destination
module" option if you merge its output into the destination module's buffer.

> while sharing a single set of buffers, slowing them all down.  Can
> you describe a scenario where this is worth the cost?

OK, I try to explain why we need to merge in kernel space instead of 
user space.

My stories are premised on the kernel flight recorder (especially, using
the relayfs buffers).

Assuming that you have to use two pre-compiled script, foo and bar.
One problem is that we cannot know how frequently each script (each
probe point) will be invoked actually. This means that we cannot know
how much memory each script needs before using it.
So, if you can use only 32MB for tracing kernel, how much memory should
you assign for each script? 
One possible solution is that you assign 16MB for each. But if the foo
and the bar consumes buffers 1MB/s and 100KB/s respectively, you can get
the data which was recorded by both scripts only latest 16 seconds.

However, if the systemtap can merge outputs of the scripts into single
buffer, you can assign 32MB for the single buffer and get the data which
was recorded by both scripts last 30 seconds.

Other possible problem will occur in adding pre-compiled scripts without 
enough amount of memory.
Assuming that you have to maintain a non-stop server by using a systemtap
script. This script has been assigned memory as big as allowed.
After the server began to work, you noticed that the script running 
on the server doesn't have enough probe points. But almost all probe
points were covered by current script.
This server is non-stop, so you should not make any blank period in the
recorded data by removing current script (the system might crash before
reloading new script).
Also, you aren't allowed to add the new script which allocates new buffer
because current script already allocated memory as big as allowed.

In this case, if the systemtap can merge outputs of the scripts into
a single buffer, you can load additional script and merge its output
to the buffer of the current script.

I believe this feature is very useful for RAS tracer.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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