Minutes of 5/5/05 meeting

[Jim Keniston <jkenisto at us dot ibm dot com>]

Minutes of SystemTAP Conference Call, May 5, 2005

Participants:
IBM:
	Larry Kessler (lkessler@us.ibm.com -- Beaverton, OR)
	Vara Prasad (varap@us.ibm.com -- Beaverton)
	Jim Keniston (jkenisto@us.ibm.com -- Beaverton)
	Hien Nguyen (nguyhien@us.ibm.com -- Beaverton)
	Ananth Mavinakayanahalli (amavin@redhat.com, ananth@in.ibm.com --
Boston)
	Prasanna Panchamukhi (prasanna@in.ibm.com -- Bangalore)
	Maneesh Soni (maneesh@in.ibm.com -- Bangalore)
	Tom Zanussi (trz@us.ibm.com -- Chicago)
Red Hat:
	Will Cohen (wcohen@redhat.com -- Raleigh)
	Frank Eigler (fche@redhat.com -- Toronto)
	Martin Hunt (hunt@redhat.com -- Seattle)
	Elena Zannoni (ezannoni@redhat.com -- Boston)
	Andrew Cagney (cagney@redhat.com)
Intel:
	Brad Chen (brad.chen@intel.com -- Santa Clara)
	Rusty Lynch (rusty@linux.co.intel.com -- Hillsboro, OR)
	Anil KeshavaMurthy (anil.s.keshavamurthy@intel.com -- Hillsboro)
	K. Sridharan (k.sridharan@intel.com -- Hillsboro)
	Charles Spirakis (charles.spirakis@intel.com)
	Rohit Seth (rohit.seth@intel.com)

Actions Required (ARs):
>From 4/28/05:
1. All: Review recent changes to archpaper/systemtap.tex.

2. All: Give Brad suggestions re: the test plan.

3. Will: Reply to Masami Hiramatsu regarding Hitachi's offer re:
SystemTap/LKST collaboration. [DONE]

4. Jim: Is __builtin_return_address() used for anything vital?
[DONE. No.]

5. Frank: Post a description of his reentrant-probe concern(s).  [DONE]

6. Ananth: Investigate Frank's reentrant-probe concern(s). [DONE.
Removing the per-probe lock.  Handlers need to be reentrant.]

7. Frank: Propose a vehicle for a SystemTap problem tracking system.
[DONE.  SystemTap bugzilla is up and accumulating bug reports.]

8. Jim: Post a summary of feedback from our prospective VM tapset
author.
[DONE]

New ARs:
9. Hien: Post return-probes patch to LKML, cc SystemTap. [DONE]

10. Will, etc: Chime in on LKML in support of return probes.

11. Hien: Notify Rusty when we feel return probes is stable enough
to start the x86_64 port.

12. Frank: Add patches directory to CVS.  [DONE]

13. kprobes authors: Check in patches and accompanying test scripts.

14. Jim: Check the assertion that kprobes handlers currently run
with interrupts enabled.  (Looks like they're disabled on i386.)

15. Rohit/all: If you want to have interrupts enabled while kprobes
handlers are run, make a case for it.

16. Frank: Propose/implement a mechanism for keeping the website
link pointing at a fresh copy of the architecture paper.


Elena reported that it's unlikely that the kprobes enhancements
required by SystemTap will be included in U2 unless they're accepted
into Linus's kernel by the U2 development code freeze.  We reviewed
the various enhancements.

Rusty can post an Itanium port of kprobes next week.  jprobes is a
problem on this architecture, so next week's patch will probably
exclude jprobes.

kprobes should be enabled by default in RHEL4 U2.

Multi-probes is in 2.6.12-rc3-mm3.

Hien will post a new patch for return probes in the next day or so.
x86_64 should be doable without too much trouble.  Rusty will do
this when he gets the go-ahead from Hien.  ppc64 is also thought
doable, but Ananth will prioritize scalability ahead of return
probes for ppc64.

The scalability would be nice to have in U2, but is lower priority
than multi-probes and return probes.

We need a repository for all these patches.  Frank will add a top-level
"patches" directory in CVS.  When checking in a patch, document
dependencies and include test scripts.

In what order should these patches be posted?  Multi-probes (already
posted), return probes (Hien will post soon), and scalability.

relayfs is in the -mm kernel, but not Linus's.  Tom says that SystemTap
is the only real user of relayfs right now.  The SystemTap runtime
is structured such that the relayfs dependency could be configured out.

Per his AR from the 4/20 meeting, Jim is working on code to run
kprobes handlers on a separate stack.  This code will be very
architecture-specific.  There are plans to store SystemTap local
variables in frames allocated from statically allocated memory, so is
the separate-stack feature still needed for kprobes?  Yes, to handle
cases where the probed function is already almost out of stack.

Switching stacks will be complicated if CONFIG_4KSTACKS is enabled
and an interrupt occurs (triggering a switch to the interrupt stack)
while the kprobes handler is running.  Aren't handlers run with
interrupts disabled?  Jim will verify.  Otherwise, one solution is
to disable interrupts while running handlers.  Is this OK?  Will and
Rohit expressed concerns about this.  But handlers are supposed to
run quickly.  If you're in favor of having interrupts enabled while
handlers are run, please make a case for it.

Prasanna posted a patch 5/5/05 that addresses a concern about
reentrancy.  If a handler hits a probepoint, we don't permanently
disarm the probe we just hit, but rather skip running the handlers.
See the "reentrant probes" thread.

Elena asked everybody to flesh out the information in their "bug"
reports in bugzilla.

Larry asked that the architecture paper link on the website be updated
to point to a more recent draft.  Frank will propose and/or implement
a mechanism for keeping this up to date.

Brad (?) proposed a ~weekly "bug scrub" session to review the status
of bugs in bugzilla.  Elena liked this idea and suggested that maybe
we could wedge this into a 15-minute slot in our Thursday conference
call.