public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* gprof cannot profile multi-threaded programs
@ 2001-01-31  5:31 Mohit Aron
  2001-01-31 14:17 ` Kurt Roeckx
  0 siblings, 1 reply; 6+ messages in thread
From: Mohit Aron @ 2001-01-31  5:31 UTC (permalink / raw)
  To: linux-kernel

Hi,
	I'm using Linux-2.2 and discovered a problem with the profiling of
a multi-threaded program (uses Linux pthreads). Basically, upon compiling
the program with '-pg' option, running it and invoking gprof on the 
gmon.out file only shows the profile information corresponding to the  
computation done by the first thread (that starts in main()). The computation
performed by any other thread (created using pthread_create()) is not 
accounted for.

I analyzed the problem to be the following. Linux uses periodic SIGPROF signals
for profiling (Linux doesn't use the profil system call used in other OS's like
Solaris where the kernel does the profiling on behalf of the process). All
profile information is collected in the context of the signal handler for the
SIGPROF signal in Linux. Unfortunately, any thread that's created using
pthread_create() does not get these periodic SIGPROF signals. Hence any thread
other than the first thread is not profiled. The fix is to use setitimer()
system call immediately in the thread startup function for any new thread to
make the SIGPROF signal to be delivered at the designated interrupt frequency
(every 10ms). With this fix, the profile produced by gprof reflects the overall
computation done by all threads in the process. A more general fix would be
to fix the kernel to make any new threads inherit the setitimer() settings
for the parent thread.

Does anyone know if this problem has already been fixed ? If so, please send me
a pointer to the patch. Thanks,


- Mohit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gprof cannot profile multi-threaded programs
@ 2001-01-31  5:38 Dan Kegel
  2001-01-31  7:27 ` Mohit Aron
  0 siblings, 1 reply; 6+ messages in thread
From: Dan Kegel @ 2001-01-31  5:38 UTC (permalink / raw)
  To: aron, linux-kernel@vger.kernel.org

See 
http://opensource.corel.com/cprof.html

I haven't used it yet, myself.

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gprof cannot profile multi-threaded programs
  2001-01-31  5:38 gprof cannot profile multi-threaded programs Dan Kegel
@ 2001-01-31  7:27 ` Mohit Aron
  2001-01-31 16:52   ` John Levon
  2001-01-31 17:13   ` Dan Kegel
  0 siblings, 2 replies; 6+ messages in thread
From: Mohit Aron @ 2001-01-31  7:27 UTC (permalink / raw)
  To: dank; +Cc: linux-kernel@vger.kernel.org


> http://opensource.corel.com/cprof.html
> 
> I haven't used it yet, myself.
> 

I have. cprof is no good - extremely slow and generates a 100MB trace
even with a simple hello world program.



- Mohit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gprof cannot profile multi-threaded programs
  2001-01-31  5:31 Mohit Aron
@ 2001-01-31 14:17 ` Kurt Roeckx
  0 siblings, 0 replies; 6+ messages in thread
From: Kurt Roeckx @ 2001-01-31 14:17 UTC (permalink / raw)
  To: Mohit Aron; +Cc: linux-kernel

On Tue, Jan 30, 2001 at 11:31:13PM -0600, Mohit Aron wrote:
> I analyzed the problem to be the following. Linux uses periodic SIGPROF signals
> for profiling (Linux doesn't use the profil system call used in other OS's like
> Solaris where the kernel does the profiling on behalf of the process). All
> profile information is collected in the context of the signal handler for the
> SIGPROF signal in Linux. Unfortunately, any thread that's created using
> pthread_create() does not get these periodic SIGPROF signals. Hence any thread
> other than the first thread is not profiled. The fix is to use setitimer()
> system call immediately in the thread startup function for any new thread to
> make the SIGPROF signal to be delivered at the designated interrupt frequency
> (every 10ms). With this fix, the profile produced by gprof reflects the overall
> computation done by all threads in the process. A more general fix would be
> to fix the kernel to make any new threads inherit the setitimer() settings
> for the parent thread.

You have the same problem when doing fork().  Only the parent
will get cpu usage info.  I have to call setitimer() too, to make
it work properly.

I complained about it a few days ago, but didn't get a reply yet.


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gprof cannot profile multi-threaded programs
  2001-01-31  7:27 ` Mohit Aron
@ 2001-01-31 16:52   ` John Levon
  2001-01-31 17:13   ` Dan Kegel
  1 sibling, 0 replies; 6+ messages in thread
From: John Levon @ 2001-01-31 16:52 UTC (permalink / raw)
  To: Mohit Aron; +Cc: linux-kernel@vger.kernel.org

On Wed, 31 Jan 2001, Mohit Aron wrote:

> 
> > http://opensource.corel.com/cprof.html
> > 
> > I haven't used it yet, myself.
> > 
> 
> I have. cprof is no good - extremely slow and generates a 100MB trace
> even with a simple hello world program.
> 

try the (currently rather alpha) oprofile, this will generate profile
info perfectly well :

http://oprofile.sourceforge.net/

(note: use CVS version, NOT the available tarball - and you might
want to wait a while for some pending updates).

I suppose further discussion should go to linuxperf@nl.linux.org or
oprofile-list@lists.sourceforge.net

thanks
john

-- 
"Existence of programs that do the impossible is 
 not a proof that that "impossible" is now possible."
	- Tigran Aivazian 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gprof cannot profile multi-threaded programs
  2001-01-31  7:27 ` Mohit Aron
  2001-01-31 16:52   ` John Levon
@ 2001-01-31 17:13   ` Dan Kegel
  1 sibling, 0 replies; 6+ messages in thread
From: Dan Kegel @ 2001-01-31 17:13 UTC (permalink / raw)
  To: Mohit Aron; +Cc: linux-kernel@vger.kernel.org

Mohit Aron wrote:
> 
> > http://opensource.corel.com/cprof.html
> >
> > I haven't used it yet, myself.
> >
> 
> I have. cprof is no good - extremely slow and generates a 100MB trace
> even with a simple hello world program.

Oh.  Bleh.

http://wordindex.sourceforge.net/testdata/usenet.col-20000817-1548/028-123.col.txt.txt
mentioned a workaround for gprof, I don't know if it's real:

> AFAIK gprof doesn't support multithreaded apps profiling, but you can
> workaround it if you call getitimer() in the main thread for ITIMER_PROF
> then using that value in a call to setitimer() in every thread you
> spawn. Other alternative is using the open source cprof by Corel [I
> never 

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-01-31 17:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-31  5:38 gprof cannot profile multi-threaded programs Dan Kegel
2001-01-31  7:27 ` Mohit Aron
2001-01-31 16:52   ` John Levon
2001-01-31 17:13   ` Dan Kegel
  -- strict thread matches above, loose matches on Subject: below --
2001-01-31  5:31 Mohit Aron
2001-01-31 14:17 ` Kurt Roeckx

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox