This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Questions about STP_TIMING
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Thu, 25 Jan 2007 18:35:01 -0500
- Subject: Re: Questions about STP_TIMING
- References: <C56DB814FAA30B418C75310AC4BB279D013CEBAA@scsmsx413.amr.corp.intel.com>
Hi -
On Thu, Jan 25, 2007 at 03:04:37PM -0800, Stone, Joshua I wrote:
> I have a couple of questions about STP_TIMING. First, why are the cycle
> counts truncated to 32-bits? [...]
This was my doing, in response to learning someplace that some popular
processors' cycle counters are relatively short before wrapping -
longer than 32 bits but shorter than 64. Since individual probe
handlers tend to run for much shorter intervals than billions of
cycles, 32 seemed like a good general compromise.
When/if we start supporting non-atomic probe handlers, then this part
will need to be revisited, for example since the "less than billions
of cycles" assumption will become invalid.
> Second, in the calculation of the delta, there's this little bit:
> // Handle 32-bit wraparound.
> o->newline() << "int32_t cycles_elapsed =3D (cycles_atend >
> cycles_atstart)";
> o->newline(1) << "? (cycles_atend - cycles_atstart)";
> o->newline() << ": (~(int32_t)0) - cycles_atstart + cycles_atend +
> 1;";
> Can you explain the need for this? [...] If you're trying to
> account for wraparound in the get_cycles() return value, you need to
> know where the wraparound occurs, right?
Not really - by masking (in this case) at 32 bits, we force a 32-bit
wraparound.
- FChE