This is the mail archive of the
mailing list for the systemtap project.
Re: using get_cycles() to get the real elapsed time
- From: "Jose R. Santos" <jrs at us dot ibm dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Li Guanglei <guanglei at cn dot ibm dot com>, "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Sat, 05 Aug 2006 22:26:53 -0500
- Subject: Re: using get_cycles() to get the real elapsed time
- References: <44D4BAB8.firstname.lastname@example.org> <email@example.com>
- Reply-to: jrs at us dot ibm dot com
Frank Ch. Eigler wrote:
Li Guanglei <firstname.lastname@example.org> writes:
> So we need deal with different Arches to get the elapsed time by
> using get_cycles()
Yes, eventually recreating the complexity of gettimeofday().
This we can offload to user space as well. I order for this to work, we
would need to specify the type of processors being used somewhere on the
trace header output.
> BTW, get_cycles() will return 32-bit value for some architectures
> e.g ppc32, although the major architectures such as ppc64, x86,
> x86_64 will all return a 64-bit value. [...]
It's even worse than that: I gather some machines return a putatively
64-bit value, but the number within overflows after a few bits past 40.
So any user of get_cycles() must correct at least for
- change in frequency
- counter overflow
- cross-CPU drift
This are some of the reasons we decided to use gettimeofday() in the
first place. Counter overflow was something that I wanted to wait for
perfmon2 which dadresses this. The problem with perfmon2 is that is
still unknown when it will be supported by SystemTap and perfmon2 still
limited CPU support.
Hopefully we will get access to system capable of doing more that 150k
IO/sec. The performance data from this system will be able to tell us
what the performance impact of gettimeofday() is and if we need to
concentrate our efforts in other tasks first.