From: Andi Kleen <ak@suse.de>
To: nagar@watson.ibm.com
Subject: Re: [Patch 1/4] Delay accounting: Initialization
Date: Wed, 16 Nov 2005 02:50:22 +0100
User-Agent: KMail/1.8.2
Cc: Peter Chubb <peterc@gelato.unsw.edu.au>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
References: <43796596.2010908@watson.ibm.com> <17274.34333.348600.111728@wombat.chubb.wattle.id.au> <437A8FED.3080508@watson.ibm.com>
In-Reply-To: <437A8FED.3080508@watson.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200511160250.23213.ak@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1081
Lines: 26

On Wednesday 16 November 2005 02:48, Shailabh Nagar wrote:

> 
> Are there problems with using sched_clock()for timestamping if one is prepared
> to live with them not necessarily being nanosecond accurate ? I'm trying to search
> the archives etc. but if you can respond with any quick comments, that'd be very
> helpful.

First it can be relatively slow on P4s (hundreds of cycles) 

On other systems it can run with different frequencies on different CPUs,
so you never need to assume a timestamp from one CPU is comparable with
the one from other CPUs (the scheduler carefully avoids this)

If you need a stable timestamp over multiple CPUs don't use it.

In general do_gettimeofday is much safer.
do_gettimeofday shouldn't be that much slower for the case where TSC
works, and where it doesn't there is no other alternative.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/