Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 17 Oct 2003 15:39:52 -0500 (CDT)
From: Brian Ford <ford AT vss DOT fsi DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Is multithreaded profiling on cygwin possible?
In-Reply-To: <20031017060238.6175.qmail@linuxmail.org>
Message-ID: <Pine.GSO.4.56.0310171512580.823@eos>
References: <20031017060238 DOT 6175 DOT qmail AT linuxmail DOT org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 17 Oct 2003, peter garrone wrote:

> Hi Brian
>
Hi Peter.  Seems like a private conversation, doesn't it? :)

>  Thanks very much for your comments.
>
You're welcome.

>  I think I have changed my approach so that it is broadly similar to
> your suggestions, but may differ in some details.
>
>  I have dropped the RNG. I dont think it is necessary or warranted.
>
I agree, especially in light of your new approach.

>  I have dropped the dll import library concept.
>
Probably good.  Although, it would still be neat to figure out a way to
trace back to the application "leaf" functions.  I guess that will be an
"exercise" for later.

>  I would agree that Corinna's suggestion about WaitForSingleObject is
> probably better, though I havent yet done it that way.
>
>  My current approach is to keep track of the time accumulated
> by each thread, and when it has exceeded the amount represented
> by a profiling period, assign the tick to the current PC,
> and subtract that amount of time from the running total for the
> thread. So it always adds up, anyway.
>
I was going to suggest this when we were talking about partial ticks, but
I was worried about charging time to the wrong PC.  Looking back, this
still fits in fine with the PC sampling "philosophy".

>  I still have it so that each thread that is to be profiled calls
> moncontrol(1). Also, an application compiled and linked without
> -pg could always use the "profil" call in a similar way.
> Each thread would call profil with identical parameters.
>
It should be simple to add an "all threads" mode later if we want, so this
is fine.  Does the main thread still call moncontrol(1) when compiled with
-pg?  I would think this would be required.

> To do the DLL's, I have added a linked list of profiling ranges
> to profil.c. These ranges are specified using an environment
> variable. The ranges may be DLL specific, or general memory ranges.
> There is a separate data file output upon program termination
> for each range, in addition to gmon.out.
>
The linked list sounds reasonable.  I guess if there were too many
threads, something less linear would be better.  Does anyone have a
suggestion about how to find these address ranges automatically (at least
for non dynamically loaded DLLs)?

I assume the gmon.out file contains just the original program proper
memory range?

I really wish we could get someone on the binutils list interested in
helping to extend the gmon.out file format to contain multiple hashes.  We
would still need a method to map the ranges to the DLLs.  Determining the
DLLs should be easy unless they were dynamically loaded.  You really
should send at least a ping over there, but you're doing all the work, so
I'll shut up now.

>  If a dll has not been stripped, gprof will use the data file
> and the dll to output a flat profile, but without call counts though.
> (At least this works with cygwin1.dll)
>
That sounds like it would be *really* usefull to cygwin developers!  This
concept was discussed before in the references I gave you, but never
pushed this far.

>  I have written a simple utility to summarise the information
> in these data files, giving flat addresses and CPU usage.
>
This sounds like a useful inclusion.  Again, it would be more functional
if we could feed all this into gprof and get partial call graphs.

Even if no one else comments, I really appreciate all this work you're
doing!  Also, thanks for continuing to send me the updated patches.  I
wish I had more time to look over them in detail right now.  I'll try and
do that soon.  I assume it is ok to give an open invitation for anyone
else who would like to give the a whirl?

BTW, if you are interested in contributing this, please take a look at the
"Before you get started" section of http://cygwin.com/contrib.html since
the assignment process can take some time.

Again, great work from my point of view!

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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/