This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Questions about STP_TIMING

From: Vara Prasad <prasadav at us dot ibm dot com>
To: "Frank Ch. Eigler" <fche at redhat dot com>
Cc: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>, systemtap at sources dot redhat dot com
Date: Fri, 26 Jan 2007 09:24:29 -0800
Subject: Re: Questions about STP_TIMING
References: <C56DB814FAA30B418C75310AC4BB279D013CEBAA@scsmsx413.amr.corp.intel.com> <20070125233501.GF30933@redhat.com>

Frank Ch. Eigler wrote:

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.

I interpret your atomic probe handlers mean the handler that runs without sleeping/pre-emption to completion. User space probes handlers can sleep (Jim correct me if i am wrong). This may be one of the things we have to revisit when we start supporting uprobes.

bye,
Vara Prasad
[snip]

References:
- Re: Questions about STP_TIMING
  - From: Frank Ch. Eigler

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]