[nptl] Re: Trace tool for RT-NPTL (Robust Mutexes)

[Tony Reix <Tony.Reix@Bull.Net>]

Hi Michael,

{     Has there been any thought of doing NPTL tracing with LTT?  If (RT-)NPTL
{ events generated LTT log entries we could use an existing tool to analyze
{ system and thread activities in the same display.
{        	   	  	     	    	 	 	Michael

Good question.
Answer is yes.

When was started the design of a tracing tool for NPTL, in 1H04, LTT was usable
only for tracing the kernel, not the user space. There were plans for providing
tools for tracing user-space code, but today I can see nothing in this area on the
LTT web-site:           http://www.opersys.com/LTT/index.html
(let me know if I'm wrong)

The way LTT is implemented now is not compatible with the constraints of the POSIX
Threads standard: very few operations are authorized, due to the "cancellation
points".
The Trace points of the NPTL Trace tool write traces into a shared memory managed as
a circular buffer, and then the traces are saved to disk by another process.

Also, LTT is clearly dedicated to tracing the kernel ("LTT is a fully-featured
tracing system for the Linux kernel"), and thus it requires to patch the kernel.
Patching the kernel can be problematic in production.

Our PTT tool (PTT: POSIX Threads NPTL Trace Tool) is dedicated to tracing NPTL,
which is part of the glibc.
It is aimed to provide traces about calls to NPTL routines but also about NPTL-internal
objects, steps and states. Also PTT is aimed to be very lite-weight and we hope
to have a lower impact to the performances than LTT (< 2.5 %) (But measures must
be done in 2005). This is required in order not to modify the sequence of execution
of threads.
The final goal is to have PTT included within the glibc, so that running an application
with or without the NPTL trace should be very easy.

PTT is aimed to provide help for 3 kinds of users:
a) developers/porters of multi-threaded applications
    Provide a way to see what's happening about threads inside the application.
    Possible extensions (in the future) could inform the developer if his application
    is POSIX compliant or not, and where. It could also provide an exact measure
    of contention, and say which threads are involved.
b) support teams
    Customers in China may produce a trace that will be analyzed in Oregon.
    No need for spending days for building a simpler environment showing the problem.
c) glibc/NPTL maintainers
    By looking to the trace, a glibc/NPTL expert could quickly say if the problem is
    	in the application, in NPTL or in the kernel.

Nevertheless, being able to merge PTT traces with LTT traces would be really useful.
We don't have studied this yet, but the post-processing tool of PTT should be able
to produce LTT-like traces.
Do you think the 2 traces could be merged ?

We plan to connect the trace tool with a GUI (Paje') dedicated to display traces of
multi-threaded applications. Thus it should help for analyzing the relation-ship between
threads, mutexes, cond-vars, semaphores, ...
Maybe PTT traces could also be displayed by means of LTT.


Cordialement/Regards,

Tony Reix
                            Carpe Diem

**********************************************************************************
Name/Company:	Tony Reix                   Bull SA - AIX/Linux R&D
EMail:		Tony.Reix@bull.net (From IBM Unix mailers: Tony.Reix@frec.bull.fr)
Position:	System Management/Java Architect - POSIX Threads - NFSv4
Web-Sites:	http://www.bull.com         http://nptl.bullopensource.org/
Address:	BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, France
Phone		France: 04 76 29 72 67      International: 33 4 76 29 72 67
Fax:		France: 04 76 29 76 00      International: 33 4 76 29 76 00
Bull:		Phone: 229-7267   MailAddress: FREC B1-188   Office: B1-225
**********************************************************************************
Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe