LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephane Eranian <eranian@hpl.hp.com>
To: Daniel Walker <dwalker@mvista.com>
Cc: linux-kernel@vger.kernel.org, venkatesh.pallipadi@intel.com,
	suresh.b.siddha@intel.com, kenneth.w.chen@intel.com,
	tony.luck@intel.com
Subject: Re: sched_clock() on i386
Date: Wed, 3 Jan 2007 06:36:02 -0800	[thread overview]
Message-ID: <20070103143602.GG7238@frankl.hpl.hp.com> (raw)
In-Reply-To: <1166889227.14081.13.camel@imap.mvista.com>

Daniel,

On Sat, Dec 23, 2006 at 07:53:47AM -0800, Daniel Walker wrote:
> On Fri, 2006-12-22 at 02:43 -0800, Stephane Eranian wrote:
> > Hello,
> > 
> > 
> > The perfmon subsystems needs to compute per-CPU duration. It is using
> > sched_clock() to provide this information. However, it seems they are
> > big variations in the way sched_clock() is implemented for each architectures,
> > especially in the accuracy of the returned value (going from TSC to jiffies).
> > 
> 
> The vast majority of architectures return a scaled jiffies value for
> sched_clock(). MIPS, and ARM for instance are two, and i386 does
> sometimes. The function isn't very predictable in terms or what you'll
> get as output. 
> 
My understanding is that you'll get a per-CPU timestamp expressed in nanoseconds.
The granularity of the returned value is highly dependent on the CPU
architecture (and apparently on how you've compiled your kernel).

> The most reliable way to get timing is to use gettimeofday() which in
> turn uses a lowlevel clock. I'm not sure exactly what your application
> is, but sometimes gettimeofday() can be a little complicated to use.
> Which is why I create the following clocksource changes,
> 
I do NOT need a wall-clock time. I am looking for a simple per-CPU clock
source with best possible granularity. I use the clock to compute elapsed
execution duration. I initially was using TSC, then during the code review
someone suggested I use sched_clock(). Using getttimeofday() can be failry
expensive and I need to compute the duration in the context switch path.

Now my understanding is that on some processors with frequence scaling,
using TSC may not easily allow computing elapsed time. So there may not
be any cheap solution to my problem.

> ftp://source.mvista.com/pub/dwalker/clocksource/
> 
> the purpose of which is to allow generic access to suitable lowlevel
> clocks. It just extends the mechanism already used by gettimeofday(). 
> 

-- 

-Stephane

      reply	other threads:[~2007-01-03 14:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-22 10:43 Stephane Eranian
2006-12-22 12:19 ` [patch] sched: improve sched_clock() on i686 Ingo Molnar
2006-12-23 10:27   ` Ingo Molnar
2007-01-17 11:05   ` Stephane Eranian
2006-12-23 15:53 ` sched_clock() on i386 Daniel Walker
2007-01-03 14:36   ` Stephane Eranian [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070103143602.GG7238@frankl.hpl.hp.com \
    --to=eranian@hpl.hp.com \
    --cc=dwalker@mvista.com \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tony.luck@intel.com \
    --cc=venkatesh.pallipadi@intel.com \
    --subject='Re: sched_clock() on i386' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).