LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephane Eranian <eranian@hpl.hp.com>
To: linux-kernel@vger.kernel.org
Cc: venkatesh.pallipadi@intel.com, suresh.b.siddha@intel.com,
	kenneth.w.chen@intel.com, tony.luck@intel.com,
	Stephane Eranian <eranian@hpl.hp.com>
Subject: sched_clock() on i386
Date: Fri, 22 Dec 2006 02:43:06 -0800	[thread overview]
Message-ID: <20061222104306.GC1895@frankl.hpl.hp.com> (raw)

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).

Looking at the i386 implementation, it is not so clear to me what the
actual goal of the function is. I was under the impression that this
function was meant to compute per-CPU time deltas. This is how the
scheduler seems to use it. 

The x86-64 and i386 implementations are quite different. The i386 comment
about NUMA seems to contradict the initial goal of the function.
Why is that?

Does this come from the fact that sched_lock() is used for the time-stamping
printk(). But in this case, like on IA-64, couldn't we define a specific
timing function for printk?


Excerpt from arch/i386/kernel/tsc.c:

unsigned long long sched_clock(void)
{
        unsigned long long this_offset;

        /*
         * in the NUMA case we dont use the TSC as they are not
         * synchronized across all CPUs.
         */
#ifndef CONFIG_NUMA
        if (!cpu_khz || check_tsc_unstable())
#endif
                /* no locking but a rare wrong value is not a big deal */
                return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);

        /* read the Time Stamp Counter: */
        rdtscll(this_offset);

        /* return the value in ns */
        return cycles_2_ns(this_offset);
}


-- 
-Stephane

             reply	other threads:[~2006-12-22 10:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-22 10:43 Stephane Eranian [this message]
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

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=20061222104306.GC1895@frankl.hpl.hp.com \
    --to=eranian@hpl.hp.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).