public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@novell.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Daniel Walker <dwalker@mvista.com>,
	linux-kernel@vger.kernel.org, johnstul@us.ibm.com,
	tglx@linutronix.de
Subject: Re: [PATCH] i386 tsc: remove xtime_lock'ing around cpufreq notifier
Date: Thu, 12 Apr 2007 20:27:14 +0200	[thread overview]
Message-ID: <200704122027.14926.ak@novell.com> (raw)
In-Reply-To: <20070412105559.385789dd.akpm@linux-foundation.org>

On Thursday 12 April 2007 19:55:59 Andrew Morton wrote:
> On Thu, 12 Apr 2007 10:43:03 -0700
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> 
> > Andrew Morton wrote:
> > > hm.  People (ab)use sched_clock() for all sorts of things nowadays.  I wouldn't
> > > do anything to degrade it just on behalf of printk-timestamping.
> > >   
> > 
> > printk was the only non-scheduler-ish use I could find.  Are there others?
> > 
> 
> blktrace.  I've seen a couple of trace/debug-style things which use
> sched_clock for timestamping event collection. I think lttng does exotic
> things with TSCs, performing private skew correction, although that might
> have changed now.

They should always just store the cpu too and educate the users that
only (cpu, timestamp) pairs make sense to compare.

That said at least my new sched_clock should not normally show 
large non differences between CPUs, so it can be usually ignored, but they can 
happen. I believe some of the already existing sched_clocks() (like the
one used on Altix) have the same property. 

But on VMI/Xen as currently implemented the differences will be large.

-Andi

  reply	other threads:[~2007-04-12 18:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-11 16:29 [PATCH] i386 tsc: remove xtime_lock'ing around cpufreq notifier Daniel Walker
2007-04-11 20:31 ` Andrew Morton
2007-04-11 20:54   ` Daniel Walker
2007-04-11 21:33     ` Andrew Morton
2007-04-12  0:39       ` Andrew Morton
2007-04-12  9:36         ` Andi Kleen
2007-04-12 16:23           ` Andrew Morton
2007-04-12 16:45             ` Andi Kleen
2007-04-12 17:00               ` Andrew Morton
2007-04-12 17:43                 ` Jeremy Fitzhardinge
2007-04-12 17:46                   ` Andi Kleen
2007-04-12 17:52                   ` Daniel Walker
2007-04-12 17:55                   ` Andrew Morton
2007-04-12 18:27                     ` Andi Kleen [this message]
2007-04-12 19:41                       ` Jeremy Fitzhardinge
2007-04-12 19:43                     ` Jeremy Fitzhardinge
2007-04-12 17:41               ` Jeremy Fitzhardinge
2007-04-12 17:45                 ` Andi Kleen
2007-04-12 19:46                   ` Jeremy Fitzhardinge
2007-04-12 20:15                     ` Andi Kleen
2007-04-12 17:17         ` Andi Kleen

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=200704122027.14926.ak@novell.com \
    --to=ak@novell.com \
    --cc=akpm@linux-foundation.org \
    --cc=dwalker@mvista.com \
    --cc=jeremy@goop.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox