This is the mail archive of the systemtap@sources.redhat.com 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]

Minutes of 6/16/05 meeting


A week or so late... Watch for 6/23 minutes Real Soon Now.
Jim

Minutes of SystemTap Conference Call, June 16, 2005

Participants:
IBM:
	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)
	Maneesh Soni (maneesh@in.ibm.com -- Bangalore)
Red Hat:
	Elena Zannoni (ezannoni@redhat.com -- Boston)
	Will Cohen (wcohen@redhat.com -- Raleigh)
	Martin Hunt (hunt@redhat.com -- Seattle)
	Frank Eigler (fche@redhat.com -- Toronto)
	Graydon Hoare (graydon@redhat.com)
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)
	Chris Elford

Actions Required (ARs):
>From 5/12/05:
17. Vara: Publish new call-in number via private email. [DONE]

>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.
[DONE, handed off to Will]

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?
[DONE: No plans to post to web site before the OLS proceedings
are published.  Vara sent a copy to external-perftools-list.]

>From 6/9/05:
25. Frank: Post matrix of kprobes features vs. architectures for
kprobes authors to fill in.  [DONE 6/14/05]

26. Rusty/Brad: Forward email address of Intel test person to Jay
Turner.

27. Charles: Document (e.g., via a tapset template) the various
approaches to timestamps and profiling, and to sequencing and
merging relayfs streams from different CPUs. [DONE 6/13 and 6/15]

>From 6/16/05:
28. All: Review Charles's documents on profiling and timestamps:
src/tapsets/{profile,timestamp} in CVS.

29. Jim: Post *probes performance measurements before and after
Rusty's recent return-probes enhancements.


There was discussion regarding the apparent bug Rusty reported
on 6/15/05 ("[kprobe bug] pre-handler changes on globals lost").
It's seen on some architectures but not on others.  (Frank later
identified the problem as an unfortunate rearrangement of code by
the compiler.)

Anil has been working on a fix for ia64 kprobes.  Due to the
non-atomicity of the instruction-replacement step, all CPUs must be
quiesced for this step.  This might have performance implications
if you're registering a lot of probes at once, but it was pointed
out that registration-time performance is unimportant compared to
probe-time performance.  There was some discussion of support for
registering a whole array of probes at once.  Rusty had investigated
this previously, and reported that the implications could be quite
messy -- e.g., if some registrations succeeded and some failed.

We need a performance suite for Kprobes.  If you have tests,
check them into CVS (to the tests tree, I guess).

Charles has checked in two tapset descriptions into CVS:
- src/tapsets/profile: general discussion of profiling
- src/tapsets/timestamp: general timestamp proposal, as discussed
on last week's call
Please review these documents.

Brad hopes to check in a static validator by 6/30/05.  The validator
will be open source.  It will be based on TIN (sp?), which is free but
not open source.  TIN is an updated version of ATOM.

Jim reported some performance results for return probes.  He will
test again with Rusty's recent patches.

Ananth has been working on the following kprobes features: SMP
scalability, ppc64 single-stepping, and backporting recent features
to the RHEL4 U2 kernel.

Some patches are in the -mm tree but not Linus's tree.  Will this
affect their acceptance into RHEL4 U2?  We must pitch these on a
case-by-case basis.  Fedora is based on Linus's kernel, so anything
accepted by Linus will flow into Fedora automatically.

Regarding the Red Hat test suite: Will can run these for i386 and
x86_64.  Looks like Ananth will handle ppc64 and Rusty will handle
ia64.

Keith Owens (?) has expressed concern over the effect of return
probes on stack unwinding.  It's not clear whether this concern
is about all architectures or ia64 specifically.

Will will check his test-system work into CVS.

Elena points out that we'll need to develop an RPM for the user-mode
parts of SystemTap.  Red Hat owns this packaging.




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