public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Kurt Garloff <garloff@suse.de>
Cc: Benjamin LaHaise <bcrl@redhat.com>,
	marcelo@conectiva.com.br, lkml <linux-kernel@vger.kernel.org>,
	"Martin J. Bligh" <Martin.Bligh@us.ibm.com>
Subject: Re: [Patch] tsc-disable_A5
Date: 17 Jun 2002 18:31:49 -0700	[thread overview]
Message-ID: <1024363910.942.32.camel@cog> (raw)
In-Reply-To: <20020618004823.GB3448@gum01m.etpnet.phys.tue.nl>

On Mon, 2002-06-17 at 17:48, Kurt Garloff wrote:
> Hi Ben,
> 
> On Fri, Jun 14, 2002 at 02:53:07PM -0400, Benjamin LaHaise wrote:
> > On Fri, Jun 14, 2002 at 11:35:26AM -0700, john stultz wrote:
> > > This results in sequential calls to gettimeofday to return
> > > non-sequential time values. By disabling the TSCs on these boxes, it
> > > forces gettimeofday to use the PIC clock instead, fixing the problem. 
> > 
> > This seems to be yet another reason for supporting per-CPU TSC 
> > calibration, as that would fix machines with different speed cpus, too.
> 
> I agree.
> Maybe the patch I once made to support CPUs with different speeds can serve
> as a starting point?
> 
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0481.html
> 
> However, one would need to make sure that all CPUs occasionally do receive
> timer interrupts, otherwise your TSC may overflow. Depending on your
> hardware (APICs), this might be an issue. I've been told that Fosters do
> misbehave ...

Hmmm, I've skimmed your patch before, but really only just for the
lowest common features bit. I didn't quite grasp it last time, but I
really like what you're doing there. TSC overflow can be almost
eliminated if we use the full 64bits, but if we can round robin the
interrupts, that would help compensate for any skew in the clocks.

Thanks for the pointer!
-john





  reply	other threads:[~2002-06-18  1:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-14 18:35 [Patch] tsc-disable_A5 john stultz
2002-06-14 18:53 ` Benjamin LaHaise
2002-06-18  0:48   ` Kurt Garloff
2002-06-18  1:31     ` john stultz [this message]
2002-06-14 18:57 ` Dave Jones
2002-06-14 19:04   ` john stultz
2002-06-14 19:56     ` Dave Jones
2002-06-14 23:29       ` Kai Germaschewski
2002-06-14 23:44         ` john stultz
2002-06-24  2:09 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2002-06-14 21:53 Mikael Pettersson
2002-06-14 22:11 ` john stultz
2002-06-15 14:13 Mikael Pettersson
2002-06-19 13:58 ` Maciej W. Rozycki

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=1024363910.942.32.camel@cog \
    --to=johnstul@us.ibm.com \
    --cc=Martin.Bligh@us.ibm.com \
    --cc=bcrl@redhat.com \
    --cc=garloff@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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