Mail Archives: cygwin/2003/10/13/18:49:28
----- Original Message -----
From: Brian Ford <ford AT vss DOT fsi DOT com>
Date: Mon, 13 Oct 2003 14:36:34 -0500 (CDT)
To: peter garrone <pgarrone AT linuxmail DOT org>
Subject: Re: Is multithreaded profiling on cygwin possible?
> On Mon, 13 Oct 2003, peter garrone wrote:
>
> >
> Sounds good, although I'm not quite sure I understand the implementation.
> What you really need to know is what thread was running just before the
> sampling thread so that it can sample the correct thread's PC. How are
> you using GetThreadTimes for this?
A list of active threads is maintained. A thread calling moncontrol(1) gets
put in the list. When a call to SuspendThread fails, the thread is assumed
to be defunct and taken off the list.
One of the fields in the thread is a counter corresponding to the sum of cpu
returned by GetThreadTimes. This function has fields corresponding to kernel cpu and
user cpu. The amount of time consumed by every thread is saved.
Generally only one thread will have consumed CPU. However to be general,
and in case the profiling thread is inadvertently delayed, all threads are
considered.
There is a partial tick problem. Suppose that a thread has consumed say
155% of the cpu time corresponding to a tick. I would assign one tick
and use a local random number generator to assign an extra tick on average 55% of the time.
I tried getting the program counter for all threads, but this was found not to work very well,
consuming excessive cpu, on average 50 milliseconds. All the other calls were of
the order of 1 microsecond. However getting the program counter only for any thread
that used cpu according to GetThreadTimes appeared to take about 50 microseconds.
Generally of course only one thread will have used CPU. The function GetThreadContext
is used to obtain the PC.
>
> I tried using a backtrace method to map the sampling time onto
> DLL leaf functions (the import stubs) once, but it did not seem possible
> to perfect. Also, that is not always what you want.
I would be interested if you would expand on this. Do you mean looking at
the stack to find the calling function?
> But, if you want this to be usefull for the community at large, attacking
> the two points in the previous email directly would probably be more
> useful. ie. Figure out a way to store the samples using a
> non-contiguous address space model, and modify gprof to load the symbol
> tables for the dependent DLLs (gdb does this to some extent). Note that
> UNIX shared libraries have similar issues. You may want to consult with
> binutils AT sources DOT redhat DOT com for a general solution since they "own" gprof.
>
I am thinking of implementing a separate profil call so that it can be used
simultaneously with -pg compilation and linking. Also a "profile-dll" call
so that profiling of the space occupied by a dll would occur.
My problem with profiling the entire dll address space is
1) The necessity of recompiling dll's so that mapping and call counting is implemented
2) The difficulty of doing anything with propriety dll's
3) The size and sparsity of the resulting gmon.out data file.
So I thought I would try attacking the problem using the import libraries.
Perhaps it is a silly idea, but if it could be made to work it avoids these problems.
If I can get it to work, I'll be back.
Thanks
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -