[Bug runtime/3858] Independent Runtime Module

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-01-28 15:07 -------
It seems like only a combination of adverse factors all being present at once
would make shared buffering necessary:

- inability to attach (in flight recorder sense) and drain data from the running
scripts
- inability to load a new combined systemtap script due to memory shortage
- buffer space constitutes the majority of memory required by the systemtap
scripts (as opposed to data variables & code)
- compatibility of different scripts' trace data in a single buffer
- acceptability of increased contention slowdowns due to shared buffer

This seems like a rare combination.  Add to that the challenge of sharing
variables across separately compiled sibling modules suggests that we should
look at another way.

How about closing this bug, given that only I/O buffering remains as a
sharing candidate.  Then, let's consider adding to the runtime a facility
for on-the-fly shrinking/growing of relay buffers, say during a
flight recorder attach/detach operation.  Then, the above scenario could
be handled with a sequence like this:

- recognize that old detached probe needs to be extended, has 16MB buffer
- compile new probe with the union of the old and new probes
- attach to old probe, consuming all data and shrinking its buffers down to
(say) 4MB
- start new probe, with small initial trace buffer, (say) 4MB
- stop old probe
- attach to new probe, extending its trace buffer back to 16 or even 32MB.

If this is a plausible solution to the administrative problem above, then
let's close this bug and add such work to the "systemtap control library"
or "flight recorder" bugs instead.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3858

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