Hi all.
I need some help to make profiling of an application on Linux. I need to
measure the computation time between different points of my program,
considering only the CPU time that the task has actually executed (i.e.
without the intervals of time that the task has been preempted by other
tasks).
To accomplish that, I can't just read the current time in different parts of
the program, nor I can set and use a timer, because this wouldn't consider
preemptions...
I found out that Linux provides the getrusage() syscall which provides the
information that I need. This syscall also says both user and system times
used by the task, which is a very useful thing.
However, it has two main drawbacks:
- its precision is very low: I'm working with real-time tasks on a Athlon-64
and I need a more accurate estimation
- it can't be invoked by a generic task to know the execution time of another
task
The only idea that I had is to insert some hooks in the kernel functions and
use some high resolution timer to compute the time that my task has
actually executed. This timer starts whenever the task obtains the CPU, and is
stopped whenever the task yields the CPU.
Therefore, I just need to know which functions are invoked when a task starts
executing on the CPU and when it looses the CPU.
May somebody tell me which are those functions ?
If somebody has suggestions about how doing this profiling, let me know.
Many thanks,
Claudio
On 10/23/05, Claudio Scordino <[email protected]> wrote:
> I need some help to make profiling of an application on Linux.
Did you already try gprof?
Jon.
On 10/24/05, Jon Masters <[email protected]> wrote:
> On 10/23/05, Claudio Scordino <[email protected]> wrote:
>
> > I need some help to make profiling of an application on Linux.
>
> Did you already try gprof?
>
or oprofile/sysprof with a recent kernel
Benoit
>>>>> "Claudio" == Claudio Scordino <[email protected]> writes:
Claudio> I found out that Linux provides the getrusage() syscall which
Claudio> provides the information that I need. This syscall also says
Claudio> both user and system times used by the task, which is a very
Claudio> useful thing.
Claudio> However, it has two main drawbacks:
Claudio> - its precision is very low: I'm working with real-time tasks
Claudio> on a Athlon-64 and I need a more accurate estimation
Claudio> - it can't be invoked by a generic task to know the execution
Claudio> time of another task
This is part of what my microstate accounting package provides
.... but I haven't done a port to AMD64 yet...
See http://www.gelato.unsw.edu.au/patches/
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*
Thank you for your suggestion, but I still have a question about it.
If I do
clock_gettime (CLOCK_THREAD_CPUTIME_ID, &old);
sleep(5);
clock_gettime (CLOCK_THREAD_CPUTIME_ID, &new);
why the difference (new-old) includes also the time the process has slept ?
Maybe there was a misunderstanding: I am looking for a way to know how long a
process has _actually_ executed, accounting for all periods that it has not
executed for some reason (like sleep, blocking, preemptions, etc.). And I
need the high precision gave by the TSC (jiffies is not enough).
getrusage works fine, but has a coarse-grain precision (jiffies).
clock_gettime, instead, has a very good precision (thanks to TSC) but as you
can see, it does not return the time that the process has actually
executed...
If I am wrong, please tell me where.
Thank you,
Claudio
On Monday 31 October 2005 18:15, you wrote:
> On 10/23/05, Claudio Scordino <[email protected]> wrote:
> > To accomplish that, I can't just read the current time in different parts
> > of the program, nor I can set and use a timer, because this wouldn't
> > consider preemptions...
>
> struct timespec start;
> clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &start);
>
> ... do work...
>
> struct timespec end;
> clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &end);
>
> ... subtract start from end
>
> Or use CLOCK_THREAD_CPUTIME_ID if this is more correct for your
> application.
>
> This works since Roland's clock work got added in the 2.6 series.
> Before that preemption wasn't excluded.