Minutes of 6/2/05 meeting

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

Minutes of SystemTap Conference Call, June 2, 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)
	Richard Moore (richardj_moore@uk.ibm.com -- Hursley, UK)
Red Hat:
	Elena Zannoni (ezannoni@redhat.com -- Boston)
	Martin Hunt (hunt@redhat.com -- Seattle)
	Frank Eigler (fche@redhat.com -- Toronto)
	Jay Turner (jkt@redhat.com, I think -- Raleigh)
Intel:
	Brad Chen (brad.chen@intel.com -- Santa Clara)
	Rusty Lynch (rusty.lynch@intel.com -- Hillsboro, OR)
	Anil KeshavaMurthy (anil.s.keshavamurthy@intel.com -- Hillsboro)
	Charles Spirakis (charles.spirakis@intel.com)

Actions Required (ARs):
>From 5/12/05:
17. Elena, Vara: Publish new call-in number via private email.
[Update: We used a Red Hat number for this morning's call, but
that presented a problem for callers from Bangalore.  Elena will
investigate, and if she can't solve the Bangalore problem, Vara will
publish a new IBM number.]

>From 5/19/05:
19. Vara: Collect sample kprobes modules and post them to the
SystemTap web site.

20. Rusty: Create a kprobes test for ia64, per his 5/12/05 design,
that tests probes on a large subset of the ia64 instruction set.
Work with Prasanna to create such tests for other architectures.
[Update: See patches/functional_kprobe_test in CVS.]

21. Rusty, Will: Look into adding kprobes tests to LDP and the
Red Hat suite, respectively.

22. Rusty: Look into x86_64 limitation re: temporary disarming of
reentrant probes.

23. Jim, Martin: Ensure that the runtime's stack-trace feature works
appropriately when there are return probes in the call stack.

>From 6/2/05:
24. Vara: Is it OK to post the OLS paper to the SystemTap web page?

Elena reviewed last week's call.

Jay Turner, a Red Hat QA expert from Raleigh, has joined the team.
Test developers from Intel and IBM should work with Jay.

Round table:

Frank has been working on the translator, and has added some needed
features.  He has also updated the architecture paper.  A new flow
diagram is posted on the SystemTap web page.  Frank estimates that we
are "a month or so away" from a translation system that is complete
enough to completely process a simple script.  Look at his notes in
bugzilla for further thoughts.

Brad sees an increasing need for how-to documentation.  Who has
tech writing resources?  src/runtime/probes/scf uses kprobes and
the SystemTap runtime to implement the sample script shown in the
OLS paper.

Rusty and Anil have been working on ia64 kprobes support.
Support is still missing for probes on many types of instructions.
These instructions need to be emulated, or probes on them need to
be rejected.  Reentrancy support has been added to the -mm kernel.
Rusty has posted a patch for x86_64 return probes.

Jim has been helping IBM engineers use kprobes, and now the SystemTap
runtime, to develop instrumentation.  Jim is working on sample
semaphore instrumentation using kprobes.

Vara has been evangelizing re: SystemTap.  He has published Take 2
on his C-language-tapset ideas.

Prasanna and Ananth have posted a patch that allows a jprobe and
one or more kprobes (including return probes) to exist at the
same address.

Prasanna is working on system-call instrumentation.  What approach
should he use, since the language and translation system are
still under development?  Of primary importance is to identify the
probe points and values to be made available at those probe points.
Should we have a goal of replacing strace?  Not exactly, since strace
can be used by non-root users on their own processes.

Ananth has posted some ppc64 cleanups.  Like x86_64, the ppc64 can't
execute an instruction in kmalloc-ed memory.  Ananth's approach to
single-stepping on ppc64 is similar to the proposed "wart-removal"
approach for x86_64: copy the instruction into a standard location and
single-step it there.  Will icache thrashing be an issue?  This may
be a relatively fine performance issue.  It's best to pursue SMP
scalability, which should make a much bigger performance difference,
first.  When we get to the icache-related tuning, also consider
situations where we can get by without a trap (e.g., the return-probe
trampoline).

Martin has been working on runtime support for aggregations and
statistics.  He has not yet done any relayfs-vs.-netlink performance
testing.

Vara and (via Elena) Will expressed their thanks for all the help
on the OLS paper.  Is it OK to distribute copies of the paper before
the OLS proceedings are published (typically a week before the
symposium, says the OLS web site)?  Probably OK internally; not
externally.  Vara will investigate.

Should we continue to use the Red Hat number to call in?  See AR #17.