[Bug runtime/3858] Independent Runtime Module

["masami dot hiramatsu dot pt at hitachi dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From masami dot hiramatsu dot pt at hitachi dot com  2007-01-29 11:35 -------
Hi Frank,

(In reply to comment #7)
> 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

- inablility to combinate several pre-compiled scripts on the customer's server.

I feel more concern about the end-users of the SystemTap, especially
System (maintenance) Engineers.
In many cases, IMHO, the gcc/kernel-debuginfo is not installed on the customer's
servers because of security and diskspace. So, we can't compile the scripts
on those servers. However, system engineers want to (or, have to) use the
systemtap to retrieve precise information on those servers.

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

I'd like to share only buffers, not variables.
I think the sharing buffer interfaces will not increase contention
slowdown. What would you think about this?

> How about closing this bug, given that only I/O buffering remains as a
> sharing candidate.

I think we might as well focus on the "I/O buffer sharing by pre-compiled
modules" issue. The title of this bug is very confusion, so I suggest that 
we should make a new entry to discuss this issue.

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

On-the-fly shrinking/growing buffers is one of good ideas.
However, unfortunately, that is not enough to me.

> - compile new probe with the union of the old and new probes

This step can't be executed on the server on which there is no
development packages installed. 

Thanks,



-- 


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.